[Bug fortran/50050] [4.6/4.7 Regression] Internal compiler error free_expr0 at expr.c:3709 via gfc_done_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50050 jpr at csc dot fi changed: What|Removed |Added CC||jpr at csc dot fi --- Comment #9 from jpr at csc dot fi 2011-08-24 06:12:58 UTC --- *** Bug 50173 has been marked as a duplicate of this bug. ***
[Bug fortran/50173] ICE when allocating derived type with allocatable component(s) and specifying lower bound
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50173 jpr at csc dot fi changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from jpr at csc dot fi 2011-08-24 06:12:58 UTC --- Hi, this seems a duplicate of the PR50050, and the suggested fix in http://gcc.gnu.org/ml/fortran/2011-08/msg00199.html works for me. Juha *** This bug has been marked as a duplicate of bug 50050 ***
[Bug fortran/50173] ICE when allocating derived type with allocatable component(s) and specifying lower bound
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50173 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-24 06:19:59 UTC --- Seems to be a duplicate of the regression caused by the patch for PR 50050, see bug 50050 comment 7. Draft patch posted at http://gcc.gnu.org/ml/fortran/2011-08/msg00199.html Sorry for the breakage! Work around: Use a version before Aug 22, 2011 - or apply Mikael's patch - or wait a couple of hours until it has been committed and then recompile.
[Bug c/50171] False positive -Wuninitialized warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50171 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-24 06:46:44 UTC --- Yeah, this is definitely not a false positive, but completely correct warning, the code is buggy. Your pseudo-inlined version isn't correct, after that t1 = -1 you need ; goto out; and out:; after t1 = 0;.
[Bug middle-end/50168] __builtin_ctz() and intrinsics __bsr(), __bsf() generate suboptimal code on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50168 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Component|c |middle-end --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-24 08:16:06 UTC --- I'd say undefined is a good enough reason to optimize the case (as opposed to target implementation defined whose behavior we'd need to preserve).
[Bug bootstrap/50167] gmp memory functions are extern C (graphite)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50167 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-08-24 CC||spop at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-24 08:16:55 UTC --- Confirmed.
[Bug c/49119] PowerPC: Wrong code with designated initializers and bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49119 Sebastian Huber sebastian.hu...@embedded-brains.de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.6.2 Resolution||FIXED Known to fail||4.6.1 --- Comment #5 from Sebastian Huber sebastian.hu...@embedded-brains.de 2011-08-24 08:20:19 UTC --- It seems that this problem is also fixed in GCC 4.6.2 20110819.
[Bug lto/50165] [4.7 Regression] Huge build time regression (Firefox lto build)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50165 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-08-24 Target Milestone|--- |4.7.0 Summary|[4.7 regression] Huge build |[4.7 Regression] Huge build |time regression (Firefox|time regression (Firefox |lto build) |lto build) Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-24 08:29:05 UTC --- Using memcmp instead of strcmp may be one reason this is slower (I think we inline strcmp but don't have any fancy memcmp inline implementations). Thus, you might want to try s/memcmp/strcmp/ in eq_string_slot_node. Also the hash-function changed by using an initial value of ds-len instead of zero. And (unsigned)ds-s[i] is not equal to (unsigned char)ds-s[i] (but no difference on x86_64). I also wonder if we can speed up string hashing by use of some fancy SSE12345 instructions. Now, in general I think we lose all the bitpack compile-time optimizations by no longer being able to inline them. They were crafted so that doing bp_pack_value (bp, val1, 12); bp_pack_value (bp, val2, 4); results in a single shift and or instructions. Now it's going to be function calls :/ Please consider moving those primitives back to a header file.
[Bug middle-end/50168] __builtin_ctz() and intrinsics __bsr(), __bsf() generate suboptimal code on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50168 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-24 09:21:11 UTC --- But it is just undefined value, not undefined behavior. If you do: --- rtlanal.c 2011-08-23 19:46:13.0 +0200 +++ rtlanal.c 2011-08-24 11:18:01.720582231 +0200 @@ -4256,21 +4256,17 @@ nonzero_bits1 (const_rtx x, enum machine case CLZ: /* If CLZ has a known value at zero, then the nonzero bits are that value, plus the number of bits in the mode minus one. */ - if (CLZ_DEFINED_VALUE_AT_ZERO (mode, nonzero)) -nonzero - |= ((unsigned HOST_WIDE_INT) 1 (floor_log2 (mode_width))) - 1; - else -nonzero = -1; + if (!CLZ_DEFINED_VALUE_AT_ZERO (mode, nonzero)) +nonzero = 0; + nonzero |= ((unsigned HOST_WIDE_INT) 1 (floor_log2 (mode_width))) - 1; break; case CTZ: /* If CTZ has a known value at zero, then the nonzero bits are that value, plus the number of bits in the mode minus one. */ - if (CTZ_DEFINED_VALUE_AT_ZERO (mode, nonzero)) -nonzero - |= ((unsigned HOST_WIDE_INT) 1 (floor_log2 (mode_width))) - 1; - else -nonzero = -1; + if (!CTZ_DEFINED_VALUE_AT_ZERO (mode, nonzero)) +nonzero = 0; + nonzero |= ((unsigned HOST_WIDE_INT) 1 (floor_log2 (mode_width))) - 1; break; case CLRSB: then __builtin_clzl (x) 0xff will happily give 0xdeadbeef as result if x happens to be 0. Similarly long y = (short) __builtin_clzl (x) will result in y being any value from LONG_MIN to LONG_MAX, instead of any value from SHORT_MIN to SHORT_MAX.
[Bug middle-end/50168] __builtin_ctz() and intrinsics __bsr(), __bsf() generate suboptimal code on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50168 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-08-24 Ever Confirmed|0 |1 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-24 09:40:44 UTC --- Hm, so the best thing we can do is a peephole recognizing that 10: 48 0f bc ff bsf%rdi,%rdi 14: 48 63 ffmovslq %edi,%rdi when rdi is zero it will stay so and the movslq is redundant?
[Bug middle-end/50168] __builtin_ctz() and intrinsics __bsr(), __bsf() generate suboptimal code on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50168
--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-24
09:45:56 UTC ---
What we IMHO should optimize and don't currently is the redundant sign
extension when using __builtin_ffsl - as it internally uses bsf + cmove,
nonzero_bits isn't able to figure out that the result of the sequence is
guaranteed to have nonzero-bits. Perhaps we should in that case add a
REG_EQUAL note to the last insn in the sequence and perhaps nonzero_bits could
also look at REG_EQUAL notes. Doing that could perhaps help even testcases
like:
int foo (long x)
{
return __builtin_popcountl (x) 0xff;
}
where the andl $0x255, %eax could be optimized away, etc.
[Bug middle-end/50168] __builtin_ctz() and intrinsics __bsr(), __bsf() generate suboptimal code on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50168 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-24 09:48:20 UTC --- (In reply to comment #7) Hm, so the best thing we can do is a peephole recognizing that 10: 48 0f bc ff bsf%rdi,%rdi 14: 48 63 ffmovslq %edi,%rdi when rdi is zero it will stay so and the movslq is redundant? I don't think so. While the SandyBridge CPU seems to behave that way, there is no such guarantee in the Intel manuals which say that the destination value is undefined if zero-flag is cleared (i.e. the source was zero) and thus some older or future CPUs might behave differently.
[Bug lto/50165] [4.7 Regression] Huge build time regression (Firefox lto build)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50165
--- Comment #3 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-08-24 09:53:24 UTC ---
The following patch fixes the problem for me:
diff --git a/gcc/data-streamer.h b/gcc/data-streamer.h
index c413a75..acf1305 100644
--- a/gcc/data-streamer.h
+++ b/gcc/data-streamer.h
@@ -92,12 +92,7 @@ static inline hashval_t
hash_string_slot_node (const void *p)
{
const struct string_slot *ds = (const struct string_slot *) p;
- hashval_t r = ds-len;
- int i;
-
- for (i = 0; i ds-len; i++)
- r = r * 67 + (unsigned)ds-s[i] - 113;
- return r;
+ return (hashval_t) htab_hash_string (ds-s);
}
/* Returns nonzero if P1 and P2 are equal. */
@@ -107,11 +102,7 @@ eq_string_slot_node (const void *p1, const void *p2)
{
const struct string_slot *ds1 = (const struct string_slot *) p1;
const struct string_slot *ds2 = (const struct string_slot *) p2;
-
- if (ds1-len == ds2-len)
-return memcmp (ds1-s, ds2-s, ds1-len) == 0;
-
- return 0;
+ return strcmp (ds1-s, ds2-s) == 0;
}
/* Returns a new bit-packing context for bit-packing into S. */
[Bug c++/33661] template methods forget explicit local reg vars
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33661 Stefan Schuh s.schuh85 at gmail dot com changed: What|Removed |Added CC||s.schuh85 at gmail dot com --- Comment #9 from Stefan Schuh s.schuh85 at gmail dot com 2011-08-24 10:00:48 UTC --- I can confirm this bug in gcc version 4.5.2 on i686-linux-gnu and in gcc version 4.6.0 on s390x-ibm-linux-gnu
[Bug tree-optimization/50067] [4.7 Regression] Wrong code with -fpredictive-commoning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50067 --- Comment #15 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-24 10:07:24 UTC --- Author: rguenth Date: Wed Aug 24 10:07:20 2011 New Revision: 178028 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178028 Log: 2011-08-24 Richard Guenther rguent...@suse.de PR tree-optimization/50067 * tree-data-ref.c (dr_analyze_indices): Do not add an access function for a MEM_REF base that has no evolution in the loop nest or that is not analyzable. * gcc.dg/torture/pr50067-3.c: New testcase. * gcc.dg/torture/pr50067-4.c: Likewise. * gcc.dg/torture/pr50067-5.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr50067-3.c trunk/gcc/testsuite/gcc.dg/torture/pr50067-4.c trunk/gcc/testsuite/gcc.dg/torture/pr50067-5.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-data-ref.c
[Bug c/49396] c-family/c-cppbuiltin.c: duplicate if expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49396 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-24 10:11:55 UTC --- Mine. Testing it now, assuming pre-approval (well, it looks obvious anyway).
[Bug fortran/50174] New: internal compiler error: derived type allocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50174 Bug #: 50174 Summary: internal compiler error: derived type allocation Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: pma...@ricardo.com Created attachment 25086 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25086 Simple module, contains type def + procedure Get ICE when compiling code with a function that allocates a derived type array. Compiled as gfortran -c settee.f90. See test file attached.
[Bug tree-optimization/50067] [4.7 Regression] Wrong code with -fpredictive-commoning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50067 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #16 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-24 10:14:29 UTC --- Ok, fixed now. There are still tons of issues, but I'll stop creating artificial testcases now as I'm somewhat tired after looking at this and thinking about this code for three days ... I eventually expect fallouts. No idea what pieces would qualify for a backport, but at least this particular bug isn't exposed on the 4.6 branch anyway.
[Bug lto/50165] [4.7 Regression] Huge build time regression (Firefox lto build)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50165
--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-24
10:16:56 UTC ---
(In reply to comment #3)
The following patch fixes the problem for me:
diff --git a/gcc/data-streamer.h b/gcc/data-streamer.h
index c413a75..acf1305 100644
--- a/gcc/data-streamer.h
+++ b/gcc/data-streamer.h
@@ -92,12 +92,7 @@ static inline hashval_t
hash_string_slot_node (const void *p)
{
const struct string_slot *ds = (const struct string_slot *) p;
- hashval_t r = ds-len;
- int i;
-
- for (i = 0; i ds-len; i++)
- r = r * 67 + (unsigned)ds-s[i] - 113;
- return r;
+ return (hashval_t) htab_hash_string (ds-s);
}
/* Returns nonzero if P1 and P2 are equal. */
@@ -107,11 +102,7 @@ eq_string_slot_node (const void *p1, const void *p2)
{
const struct string_slot *ds1 = (const struct string_slot *) p1;
const struct string_slot *ds2 = (const struct string_slot *) p2;
-
- if (ds1-len == ds2-len)
-return memcmp (ds1-s, ds2-s, ds1-len) == 0;
-
- return 0;
+ return strcmp (ds1-s, ds2-s) == 0;
}
/* Returns a new bit-packing context for bit-packing into S. */
Can you check if keeping the ds1-len == ds2-len check in eq_string_slot_node
but using strcmp works as well? If not, then it seems -len is not
properly initialized in all cases (which would explain that changing the
hash is also important).
[Bug c/49119] PowerPC: Wrong code with designated initializers and bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49119 --- Comment #6 from Mikael Pettersson mikpe at it dot uu.se 2011-08-24 10:25:39 UTC --- For the record, this was fixed on 4.6 branch by r176438, the fix for PR49768. The test cases are essentially the same, so PR49119 is a dupe of PR49768.
[Bug c/49119] PowerPC: Wrong code with designated initializers and bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49119 Sebastian Huber sebastian.hu...@embedded-brains.de changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #7 from Sebastian Huber sebastian.hu...@embedded-brains.de 2011-08-24 10:34:05 UTC --- Thanks for the pointer. *** This bug has been marked as a duplicate of bug 49768 ***
[Bug tree-optimization/49768] [4.6/4.7 Regression] C99 style union initializations does not work as expected with optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49768 Sebastian Huber sebastian.hu...@embedded-brains.de changed: What|Removed |Added CC||sebastian.huber@embedded-br ||ains.de --- Comment #11 from Sebastian Huber sebastian.hu...@embedded-brains.de 2011-08-24 10:34:05 UTC --- *** Bug 49119 has been marked as a duplicate of this bug. ***
[Bug lto/50165] [4.7 Regression] Huge build time regression (Firefox lto build)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50165
--- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-24
10:37:18 UTC ---
Btw, as -len includes the trailing zero, the new hash function hashes in
a zero and the memcmp compares one byte unnecessarily. To make the transform
1:1 it would be
static inline hashval_t
hash_string_slot_node (const void *p)
{
const struct string_slot *ds = (const struct string_slot *) p;
hashval_t r = 0;
int i;
for (i = 0; i ds-len - 1; i++)
r = r * 67 + (unsigned char)ds-s[i] - 113;
return r;
}
static inline int
eq_string_slot_node (const void *p1, const void *p2)
{
const struct string_slot *ds1 = (const struct string_slot *) p1;
const struct string_slot *ds2 = (const struct string_slot *) p2;
if (ds1-len == ds2-len)
return strncmp (ds1-s, ds2-s, ds1-len - 1) == 0;
return 0;
}
which, if it works fine, would be ok with me.
[Bug lto/50165] [4.7 Regression] Huge build time regression (Firefox lto build)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50165 --- Comment #6 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-08-24 10:41:15 UTC --- (In reply to comment #4) - - if (ds1-len == ds2-len) -return memcmp (ds1-s, ds2-s, ds1-len) == 0; - - return 0; + return strcmp (ds1-s, ds2-s) == 0; } /* Returns a new bit-packing context for bit-packing into S. */ Can you check if keeping the ds1-len == ds2-len check in eq_string_slot_node but using strcmp works as well? If not, then it seems -len is not properly initialized in all cases (which would explain that changing the hash is also important). No, keeping the (ds1-len == ds2-len) check doesn't work.
[Bug middle-end/50083] [4.7 regression] All 32-bit fortran tests fail on 32-bit Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50083
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE 2011-08-24 10:43:58 UTC ---
--- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2011-08-23
18:16:49 UTC ---
(In reply to comment #2)
Created attachment 25058 [details]
Proposed patch to fallback to lround call
I can't trigger the problem on Linux, can you please test attached patch - or
eventually provide a testcase with all necessary compile flags.
Clock starts ticking ...
Sorry, I missed this. The following test (reduced from
libgfortran/intrinsics/c99_functions.c) fails for me:
$ cat iround.i
float roundf (float x);
long int
lroundf (float x)
{
return (long int) roundf (x);
}
$ ./cc1 -quiet -O2 -march=pentiumpro iround.i
$ cat iround.s
.file iround.i
.text
.align 16
.globl lroundf
.type lroundf, @function
lroundf:
.LFB0:
.cfi_startproc
jmp __builtin_iroundf
.cfi_endproc
.LFE0:
.size lroundf, .-lroundf
.ident GCC: (GNU) 4.7.0 20110819 (experimental) [trunk revision
177911]
I'll try the patch next thing.
Rainer
[Bug lto/50165] [4.7 Regression] Huge build time regression (Firefox lto build)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50165 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-24 10:46:17 UTC --- (In reply to comment #6) (In reply to comment #4) - - if (ds1-len == ds2-len) -return memcmp (ds1-s, ds2-s, ds1-len) == 0; - - return 0; + return strcmp (ds1-s, ds2-s) == 0; } /* Returns a new bit-packing context for bit-packing into S. */ Can you check if keeping the ds1-len == ds2-len check in eq_string_slot_node but using strcmp works as well? If not, then it seems -len is not properly initialized in all cases (which would explain that changing the hash is also important). No, keeping the (ds1-len == ds2-len) check doesn't work. Oh dear. I'll leave it for Diego to investigate then :) At this point (well, and everywhere else, including in the hash function) gcc_assert (ds1-len == strlen (ds1-s) + 1 ds2-len == strlen (ds2-s) + 1); should hold.
[Bug middle-end/50083] [4.7 regression] All 32-bit fortran tests fail on 32-bit Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50083 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-08-24 10:47:56 UTC --- At least rebuilding cc1 with the patched builtins.c doesn't make a difference. Rainer
[Bug target/43052] [4.7 Regression] Inline memcmp is *much* slower than glibc's, no longer expanded inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target|i486-linux-gnu |x86_64-*-*, i?86-*-*
CC||rth at gcc dot gnu.org,
||uros at gcc dot gnu.org
Target Milestone|--- |4.7.0
Summary|Inline memcmp is *much* |[4.7 Regression] Inline
|slower than glibc's |memcmp is *much* slower
||than glibc's, no longer
||expanded inline
--- Comment #16 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-24
10:56:00 UTC ---
Since
2011-08-12 Nick Clifton ni...@redhat.com
* builtins.c (expand_builtin_memcmp): Do not use cmpstrnsi pattern.
* doc/md.texi (cmpstrn): Note that the comparison stops if both
fetched bytes are zero.
(cmpstr): Likewise.
(cmpmem): Note that the comparison does not stop if both of the
fetched bytes are zero.
we no longer expand memcmp inline as x86 does not have a cmpmemsi pattern.
Testcase:
int foo(char *s, char *q)
{
return memcmp (s, q, 4);
}
the 1-size case is folded to *s == *q.
This is now a regression, we have to do _something_ about it for 4.7,
at least for constant small sizes.
[Bug c/50171] False positive -Wuninitialized warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50171
--- Comment #3 from Kirill A. Shutemov kirill at shutemov dot name 2011-08-24
10:57:30 UTC ---
Sorry, I've made mistake trying to simplify the test case.
Is it still correct to generate warning for the code below?
int error(void);
int baz(char **, const char *);
int quux(char *);
static int bar(char **out, const char *in)
{
char *t;
int err;
err = baz(t, in);
if (err 0)
return error();
*out = t;
return 0;
}
int foo(const char *a)
{
int err;
char *b;
err = bar(b, a);
if (err 0)
return error();
return quux(b);
}
[Bug c/49396] c-family/c-cppbuiltin.c: duplicate if expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49396 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-24 11:17:02 UTC --- Author: rguenth Date: Wed Aug 24 11:16:57 2011 New Revision: 178032 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178032 Log: 2011-08-24 Richard Guenther rguent...@suse.de PR c/49396 c-family/ * c-cppbuiltin.c (c_cpp_builtins_optimize_pragma): Fix conditional. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-cppbuiltin.c
[Bug c/49396] c-family/c-cppbuiltin.c: duplicate if expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49396 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-24 11:28:10 UTC --- Fixed for 4.7.0.
[Bug c/50171] False positive -Wuninitialized warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50171 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-24 11:29:35 UTC --- Yes, if error does not return a value 0 then it will be used uninitialized.
[Bug fortran/50174] [4.7 Regression] ICE on derived type allocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50174 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Summary|internal compiler error:|[4.7 Regression] ICE on |derived type allocation |derived type allocation --- Comment #1 from janus at gcc dot gnu.org 2011-08-24 11:34:30 UTC --- Confirmed on 4.7 trunk. Works on 4.6. Reduced test case: implicit none type settee real,allocatable :: seat(:) end type settee integer :: is = 1, ie = 3 type(settee),allocatable :: set1(:) allocate (set1(is:ie)) end
[Bug fortran/50174] [4.7 Regression] ICE on derived type allocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50174 --- Comment #2 from janus at gcc dot gnu.org 2011-08-24 11:36:35 UTC --- Probably related to PR 50050.
[Bug debug/49864] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2439
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49864 --- Comment #7 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-08-24 12:36:57 UTC --- Created attachment 25087 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25087 assert-i.c Set to REOPENED: This bug is still not dead; I see it with r178035 from trunk for the attached, precompiled file from avr-libc. There are similar PRs PR49994, PR49879 which all are fixed. I chose to reopen this one because it occurs for the same target and similar message. == Command line == avr-gcc assert-i.c -S -Os -g -v Using built-in specs. COLLECT_GCC=avr-gcc COLLECT_LTO_WRAPPER=/local/gnu/install/gcc-4.7/libexec/gcc/avr/4.7.0/lto-wrapper Target: avr Configured with: ../../gcc.gnu.org/trunk/configure --target=avr --prefix=/local/gnu/install/gcc-4.7 --disable-nls --disable-shared --enable-languages=c,c++ --with-dwarf2 --disable-lto Thread model: single gcc version 4.7.0 20110824 (experimental) (GCC) COLLECT_GCC_OPTIONS='-S' '-Os' '-g' '-v' /local/gnu/install/gcc-4.7/libexec/gcc/avr/4.7.0/cc1 -quiet -v assert-i.c -quiet -dumpbase assert-i.c -auxbase assert-i -g -Os -version -o assert-i.s GNU C (GCC) version 4.7.0 20110824 (experimental) (avr) compiled by GNU C version 4.3.2 [gcc-4_3-branch revision 141291], GMP version 5.0.1, MPFR version 3.0.0-p8, MPC version 0.8.2 ... assert-i.c: In function '__assert': assert-i.c:36:1: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2234 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug debug/49864] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2439
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49864 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #8 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-08-24 12:50:47 UTC --- Reopened, changing status from attachement dialog seems to ignore it...
[Bug fortran/50163] [4.3/4.4/4.5/4.6/4.7 Regression] ICE: initialization expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50163 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-24 13:11:14 UTC --- Author: burnus Date: Wed Aug 24 13:11:08 2011 New Revision: 178038 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178038 Log: 2011-08-24 Tobias Burnus bur...@net-b.de PR fortran/50163 * expr.c (check_init_expr): Return when an error occured. 2011-08-24 Tobias Burnus bur...@net-b.de PR fortran/50163 * gfortran.dg/initialization_28.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/initialization_28.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug target/50172] AVX2 test failures for x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50172 --- Comment #2 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-08-24 13:25:30 UTC --- Author: hjl Date: Wed Aug 24 13:25:22 2011 New Revision: 178040 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178040 Log: Mention PR target/50172. Modified: trunk/gcc/ChangeLog
[Bug target/50172] AVX2 test failures for x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50172 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2011-08-24 13:27:33 UTC --- Fixed.
[Bug fortran/50163] [4.3/4.4/4.5/4.6/4.7 Regression] ICE: initialization expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50163 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug libgomp/50175] New: data race with barrier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50175 Bug #: 50175 Summary: data race with barrier Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch I'm using valgrind together with the drd tool to find data races in my OMPed code. However, one warning traces back to libgomp, as illustrated by the simple test program below. As instructed in the drd manual, gcc has been configured with --disable-linux-futex Note also that the warning only happens with 3 or more threads. cat test.f90 !$OMP PARALLEL !$OMP BARRIER !$OMP END PARALLEL END gfortran -fopenmp test.f90 export OMP_NUM_THREADS=3 valgrind --tool=drd ./a.out ==12681== drd, a thread error detector ==12681== Copyright (C) 2006-2010, and GNU GPL'd, by Bart Van Assche. ==12681== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==12681== Command: ./a.out ==12681== ==12681== Conflicting store by thread 1 at 0x0618c28c size 4 ==12681==at 0x53B297D: gomp_team_barrier_wait (bar.h:66) ==12681==by 0x53B1D2E: gomp_team_end (team.c:464) ==12681==by 0x40072A: MAIN__ (in /data03/vondele/bugs/a.out) ==12681==by 0x400760: main (in /data03/vondele/bugs/a.out) ==12681== Address 0x618c28c is at offset 236 from 0x618c1a0. Allocation context: ==12681==at 0x4C29301: malloc (vg_replace_malloc.c:236) ==12681==by 0x53AD018: gomp_malloc (alloc.c:36) ==12681==by 0x53B165C: gomp_new_team (team.c:144) ==12681==by 0x53B078B: GOMP_parallel_start (parallel.c:108) ==12681==by 0x40071B: MAIN__ (in /data03/vondele/bugs/a.out) ==12681==by 0x400760: main (in /data03/vondele/bugs/a.out) ==12681== Other segment start (thread 2) ==12681==at 0x4C31759: sem_wait (drd_pthread_intercepts.c:1010) ==12681==by 0x53B265B: gomp_sem_wait (sem.c:120) ==12681==by 0x53B28DB: gomp_team_barrier_wait_end (bar.c:146) ==12681==by 0x400778: MAIN__._omp_fn.0 (in /data03/vondele/bugs/a.out) ==12681==by 0x53B159F: gomp_thread_start (team.c:115) ==12681==by 0x4C295F0: vgDrd_thread_wrapper (drd_pthread_intercepts.c:281) ==12681==by 0x5A09A4E: start_thread (in /lib64/libpthread-2.11.2.so) ==12681==by 0x5CF082C: clone (in /lib64/libc-2.11.2.so) ==12681== Other segment end (thread 2) ==12681==at 0x5A10EB4: __lll_lock_wait (in /lib64/libpthread-2.11.2.so) ==12681==by 0x5A0C2A3: _L_lock_999 (in /lib64/libpthread-2.11.2.so) ==12681==by 0x5A0C0B8: pthread_mutex_lock (in /lib64/libpthread-2.11.2.so) ==12681==by 0x4C2B7B4: pthread_mutex_lock (drd_pthread_intercepts.c:586) ==12681==by 0x53B2968: gomp_team_barrier_wait (mutex.h:44) ==12681==by 0x53B15AB: gomp_thread_start (team.c:116) ==12681==by 0x4C295F0: vgDrd_thread_wrapper (drd_pthread_intercepts.c:281) ==12681==by 0x5A09A4E: start_thread (in /lib64/libpthread-2.11.2.so) ==12681==by 0x5CF082C: clone (in /lib64/libc-2.11.2.so) ==12681== ==12681== ==12681== For counts of detected and suppressed errors, rerun with: -v ==12681== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 31 from 31)
[Bug tree-optimization/50138] [4.6 Regression] ICE in vect_transform_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50138 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-08-24 CC||jakub at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-24 14:16:08 UTC --- On the trunk started likely with http://gcc.gnu.org/viewcvs?root=gccview=revrev=161797 and got fixed with http://gcc.gnu.org/viewcvs?root=gccview=revrev=173132 (aka PR48765). Not sure if that patch is safely backportable though.
[Bug target/43052] [4.7 Regression] Inline memcmp is *much* slower than glibc's, no longer expanded inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052 --- Comment #17 from Jan Hubicka hubicka at gcc dot gnu.org 2011-08-24 14:20:29 UTC --- Hmm, I guess ideally the middle-end should know how to inline the simple loop (for both strlen and memcmp) and do so when object size is known to be small (probably by target specific value). Or does anyone think it is a bad idea? We could then make i386 backend to again inline the rep instruction and/or the new string extensions Honza
[Bug fortran/50174] [4.7 Regression] ICE on derived type allocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50174 --- Comment #3 from janus at gcc dot gnu.org 2011-08-24 14:36:22 UTC --- (In reply to comment #2) Probably related to PR 50050. Apparently it is fixed by Mikael's patch at http://gcc.gnu.org/ml/fortran/2011-08/msg00199.html
[Bug target/43052] [4.7 Regression] Inline memcmp is *much* slower than glibc's, no longer expanded inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052 --- Comment #18 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-24 14:36:45 UTC --- (In reply to comment #17) Hmm, I guess ideally the middle-end should know how to inline the simple loop (for both strlen and memcmp) and do so when object size is known to be small (probably by target specific value). Or does anyone think it is a bad idea? I think that's a bad idea, yes. Apart from maybe simple cases we already handle for memcpy - assignment simplifications (thus, aligned compares up to word_mode size), but supposedly only if the result is checked for ==/!= 0 only(?).
[Bug target/50176] New: [4.6/4.7 Regression] 4.7 generates spill-fill dealing with char-int conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50176 Bug #: 50176 Summary: [4.6/4.7 Regression] 4.7 generates spill-fill dealing with char-int conversion Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: izamya...@gmail.com Created attachment 25088 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25088 testcase for the problem I observe that for attached testcase (made from one of tests from EEMBC 2.0 suite) 4.7 generates spill-fill pair when (I suspect) dealing with char-int conversion while 4.6 doesn't generate them. Asm for 4.7 for lines 42-47 from the testcase: .LVL7: # test_4_6.c:42 .loc 1 42 0 discriminator 2 movl8(%esp), %edx # test_4_6.c:45 .loc 1 45 0 discriminator 2 movl0(,%edi,4), %esi # test_4_6.c:42 .loc 1 42 0 discriminator 2 movzbl (%edx,%eax), %edx edx contains cb frome line 42 # test_4_6.c:40 .loc 1 40 0 discriminator 2 addl$1, %eax # test_4_6.c:45 .loc 1 45 0 discriminator 2 addl%ebx, %esi # test_4_6.c:42 .loc 1 42 0 discriminator 2 movb%dl, 3(%esp) - spill, line 42 .LVL8: # test_4_6.c:45 .loc 1 45 0 discriminator 2 movzbl (%esi), %edx # test_4_6.c:47 .loc 1 47 0 discriminator 2 movzbl 3(%esp), %esi - fill, line 47 # test_4_6.c:45 .loc 1 45 0 discriminator 2 movb%dl, (%ecx) # test_4_6.c:47 .loc 1 47 0 discriminator 2 movl0(,%esi,4), %edx --- using cb, line 47 addl0(,%edi,4), %edx sarl$16, %edx # test_4_6.c:46 .loc 1 46 0 discriminator 2 movzbl (%ebx,%edx), %edx # test_4_6.c:49 .loc 1 49 0 discriminator 2 addl0(,%esi,4), %ebx - using cb, line 49 Meanwhile, 4.6 does not have such problem: .LVL7: # test_4_6.c:42 .loc 1 42 0 discriminator 2 movl4(%esp), %edx movzbl (%edx,%eax), %esi -- esi=cb and is used later without spills .LVL8: # test_4_6.c:40 .loc 1 40 0 discriminator 2 addl$1, %eax # test_4_6.c:45 .loc 1 45 0 discriminator 2 movl0(,%edi,4), %edx addl%ebx, %edx movzbl (%edx), %edx movb%dl, (%ecx) # test_4_6.c:47 .loc 1 47 0 discriminator 2 movl0(,%esi,4), %edx using cb, line 47 addl0(,%edi,4), %edx sarl$16, %edx # test_4_6.c:46 .loc 1 46 0 discriminator 2 movzbl (%ebx,%edx), %edx # test_4_6.c:49 .loc 1 49 0 discriminator 2 addl0(,%esi,4), %ebx using cb, line 49 After expanding 4.7 contains: (insn 52 51 53 6 (set (reg:QI 83 [ D.2723 ]) (mem:QI (plus:SI (reg/v/f:SI 75 [ inptr1 ]) (reg/v:SI 117 [ col ])) [0 MEM[base: inptr1_19, index: col_90, offset: 0B]+0 S1 A8])) test_4_6.c:42 -1 (nil)) and 4.6 contains (insn 52 51 53 6 (parallel [ (set (reg/v:SI 86 [ cb ]) (zero_extend:SI (mem:QI (plus:SI (reg/v/f:SI 76 [ inptr1 ]) (reg/v:SI 78 [ col ])) [0 MEM[base: inptr1_19, index: col_22, offset: 0B]+0 S1 A8]))) (clobber (reg:CC 17 flags)) ]) test_4_6.c:42 -1 (nil)) Options are: -c -g -m32 -O2 test.c GCC 4.6 is Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/export/users/izamyati/prefix Thread model: posix gcc version 4.6.0 20110215 (experimental) (GCC) GCC 4.7 is Target: x86_64-unknown-linux-gnu Configured with: ../configure --disable-bootstrap --enable-languages=c,c++ --prefix=/export/users/izamyati/prefix_4_7 Thread model: posix gcc version 4.7.0 20110824 (experimental) (GCC)
[Bug libgomp/50175] data race with OMP barrier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50175 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||rth at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-24 14:55:18 UTC --- If this is about bar-arrived writes, then I don't see any races. During the lifetime of a barrier, in the first phase arrived is incremented by each thread, guarded by bar-mutex1 lock. The threads then unlock bar-mutex1 lock, except for the last thread which keeps it locked and decrements bar-arrived again, then, still with bar-mutex1 locked wakes up all the other threads which then either atomically, or guarded with bar-mutex2 lock, decrement bar-arrived again. The last of those threads then posts to bar-sem2 semaphore on which the thread holding bar-mutex1 is waiting before unlocking that lock. Thus, I don't see how the first phase (where bar-arrived adjustments are done guarded with bar-mutex1 lock) can overlap with the second phase (where it is decremented atomically or with mutex2). Not even the second phase with following first phase. Thus I think valgrind is wrong about this. CCing rth as author...
[Bug bootstrap/50103] gcc-4.4.6/gcc/config/rs6000/rs6000.md:153: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50103 --- Comment #3 from Sri murthys at us dot ibm.com 2011-08-24 15:02:15 UTC --- I tried with -O0 and also tried with a different version of the compiler - I was using Vac 11.1.0.0 when I originally reported the problem. I changed to 9.0.0.16 and even with that compiler the bootstrap fails at the same place with the same message. Can you please suggest the next step in debugging this issue? Thank you. Sridhar
[Bug target/44618] [4.4/4.5 regression] wrong code with -frename-registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618 --- Comment #30 from Edmar Wienskoski edmar at freescale dot com 2011-08-24 15:06:48 UTC --- Not really. A year ago when I opened the bug, it was affecting all branches. When it was finally approved (David E.), I re-factored the patch. At this point I found 4.4 did not need the patch any more. I submitted patch for all others (4.5, 4.6, 4.7). As I sad before, it was already approved, but I depend on David to do the commit as I don't have WAA. He said he was busy, it took almost 2 weeks for him to do the commit on 4.7, few days latter it came the commit on 4.6. And the 4.5 never came... Edmar On 08/23/2011 11:57 PM, galak at kernel dot crashing.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618 Kumar Galagalak at kernel dot crashing.org changed: What|Removed |Added CC||galak at kernel dot ||crashing.org --- Comment #29 from Kumar Galagalak at kernel dot crashing.org 2011-08-24 04:57:31 UTC --- (In reply to comment #27) Author: jakub Date: Thu Jun 16 07:49:58 2011 New Revision: 175093 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175093 Log: 2011-06-13 Edmar Wienskoskied...@freescale.com PR target/44618 * config/rs6000/rs6000.md (save_gpregs_mode): Replaced pattern with a set of similar patterns, where the MATCH_OPERAND for the function argument is replaced with individual references to hardware registers. (save_fpregs_mode): Ditto (restore_gpregs_mode): Ditto (return_and_restore_gpregs_mode): Ditto (return_and_restore_fpregs_mode): Ditto (return_and_restore_fpregs_aix_mode): Ditto * gcc.target/powerpc/outofline_rnreg.c: New testcase. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog Any reason this wasn't applied to 4.5 branch?
[Bug bootstrap/50177] New: libcpp reallocator a C or C++ function?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50177
Bug #: 50177
Summary: libcpp reallocator a C or C++ function?
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org
Hello,
another issue (last one for now) with using a non-gcc C++ compiler for stage1:
in libcpp, struct line_maps has a member reallocator of type line_map_realloc
(a typedef for a pointer to function). The various values it gets assigned in
gcc are 0, xmalloc and realloc_for_line_map (from gcc/toplev.c). The second one
is an extern C function and the last one a C++ function, which in C++ are
different types. g++ can't tell the difference (yet? see Bug 2316), but some
other compilers can (sunpro). We should decide whether line_map_realloc is
supposed to be a C or C++ function and be consistent about it.
Note that if we only care about letting sunpro pass, the following only warns
instead of producing an error (a cast of xrealloc to line_map_realloc might do
the same):
--- libcpp/line-map.c (revision 176961)
+++ libcpp/line-map.c (working copy)
@@ -95,8 +95,9 @@
if (set-used == set-allocated)
{
- line_map_realloc reallocator
- = set-reallocator ? set-reallocator : xrealloc;
+ line_map_realloc reallocator;
+ if(set-reallocator) reallocator=set-reallocator;
+ else reallocator=xrealloc;
set-allocated = 2 * set-allocated + 256;
set-maps
= (struct line_map *) (*reallocator) (set-maps,
[Bug target/50164] [IRA, 4.7 Regression] Performance degradation due to increased memory instructions count
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50164 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC||vmakarov at redhat dot com --- Comment #1 from Vladimir Makarov vmakarov at redhat dot com 2011-08-24 16:02:57 UTC --- Yesterday I sent a patch http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01954.html which most probably solved the problem. Now I have code size 419 (gcc 4.6) vs 411 (gcc as of Aug 24) bytes for the test.
[Bug fortran/50050] [4.6/4.7 Regression] Internal compiler error free_expr0 at expr.c:3709 via gfc_done_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50050 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug c/18624] GCC does not detect local variable set but never used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18624 --- Comment #27 from Bernhard Reutner-Fischer aldot at gcc dot gnu.org 2011-08-24 17:14:19 UTC --- FIXED? Seems that this is supported in c++ nowadays, thanks to dodji.
[Bug middle-end/50178] New: [4.6 regression] ICE with gfortran -O3, not with gfortran -02
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50178 Bug #: 50178 Summary: [4.6 regression] ICE with gfortran -O3, not with gfortran -02 Classification: Unclassified Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: t...@moene.org Created attachment 25089 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25089 Source code of the failing compilation. Compiling the attached source code with gfortran 4.6.1 using optimization -O3 leads to the following Internal Compiler Error: $ gfortran -O3 -c suedyn.f90 suedyn.f90: In function ‘suedyn’: suedyn.f90:10:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. Compiling with -O2 instead succeeds (hence my suspicion that it is a middle-end failure).
[Bug middle-end/50178] [4.6 regression] ICE with gfortran -O3, not with gfortran -02
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50178 Toon Moene toon at moene dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-08-24 Ever Confirmed|0 |1 --- Comment #1 from Toon Moene toon at moene dot org 2011-08-24 17:21:23 UTC --- The source code as attached is much reduced from the original, courtesy of Steve Kargl. Dominique Dhumieres wrote: It started to fail between revisions 158105 and 158252 and it has been fixed on 4.7 between revisions 174599 and 175148. in this note: http://gcc.gnu.org/ml/fortran/2011-08/msg00198.html
[Bug c/18624] GCC does not detect local variable set but never used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18624 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #28 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-24 17:21:21 UTC --- Fixed.
[Bug c/50179] New: wrong set but not used warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50179
Bug #: 50179
Summary: wrong set but not used warning
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: al...@gcc.gnu.org
To me it looks like the warning below is not correct. The variable is in fact
used.
$ gcc-4.6 -c -o bug.o bug.c -Wall
bug.c: In function ‘huh’:
bug.c:5:15: warning: variable ‘b__’ set but not used
[-Wunused-but-set-variable]
$ cat bug.c
#include stdio.h
void huh(void) {
printf(%s, (__extension__(
{
static char b__[129];
b__[0] = 1;
b__[1] = 2;
b__[2] = 0;
b__;
}))
);
}
[Bug target/50090] ARM EABI symbols in libgcc.a have default visibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50090 --- Comment #3 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-08-24 17:21:52 UTC --- Author: rsandifo Date: Wed Aug 24 17:21:48 2011 New Revision: 178043 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178043 Log: libgcc/ PR target/50090 * config/arm/bpabi-lib.h (RENAME_LIBRARY_SET): Delete. (RENAME_LIBRARY): Use a C-level alias instead of an assembly one. Modified: branches/gcc-4_6-branch/libgcc/ChangeLog branches/gcc-4_6-branch/libgcc/config/arm/bpabi-lib.h
[Bug middle-end/50178] [4.6 regression] ICE with gfortran -O3, not with gfortran -02
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50178 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-24 17:42:00 UTC --- From http://gcc.gnu.org/ml/fortran/2011-08/msg00197.html 4.6.2-20110818 (Rev. 177878) crashes at: ==27008== Invalid read of size 8 ==27008==at 0x89A58F: vect_is_simple_use_1 (tree-vect-stmts.c:5346) ==27008==by 0x89B4E5: vectorizable_operation (tree-vect-stmts.c:2440) ==27008==by 0x89F452: vect_transform_stmt (tree-vect-stmts.c:4841) ==27008==by 0x8ACB23: vect_transform_loop (tree-vect-loop.c:4872) ==27008==by 0x8B66E9: vectorize_loops (tree-vectorizer.c:205)
[Bug go/50166] ICE in go1: SEGV on Solaris 10/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50166 --- Comment #1 from Ian Lance Taylor ian at airs dot com 2011-08-24 17:59:14 UTC --- I haven't been able to recreate this crash yet. According to the backtrace the crash occurs the very first time a value is added to Integer_type::named_integer_types, which is a std::map. The backtrace seems to show that the code is trying to decrement a variable set to end(), which crashes because the map is empty. I don't know why this is happening. With the information I have so far it does not seem to be Go related.
[Bug target/50176] [4.6/4.7 Regression] 4.7 generates spill-fill dealing with char-int conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50176 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug target/50164] [IRA, 4.7 Regression] Performance degradation due to increased memory instructions count
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50164 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug target/50176] [4.6/4.7 Regression] 4.7 generates spill-fill dealing with char-int conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50176 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-08-24 18:09:44 UTC --- Is this only a 4.7 regression?
[Bug middle-end/50178] [4.6 regression] ICE with gfortran -O3, not with gfortran -02
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50178 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-08-24 18:20:01 UTC --- The code compiles with gfortran 4.6.1 and -O3 -ffast-math.
[Bug middle-end/50178] [4.6 regression] ICE with gfortran -O3, not with gfortran -02
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50178 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||irar at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-24 18:52:07 UTC --- Fixed by http://gcc.gnu.org/viewcvs?root=gccview=revrev=175074 (or perhaps just made latent, hard to say).
[Bug c/18624] GCC does not detect local variable set but never used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18624 --- Comment #29 from alexander.herrmann at aiengine dot org 2011-08-24 19:21:47 UTC --- Dear Jakub, I just did try the example code with gcc 4.5.2. It plain c not c++. Some oldfashioned people still use c ;) Regards, Alexander J. Herrmann 2011/8/25 jakub at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18624 Jakub Jelinek jakub at gcc dot gnu.org changed: What |Removed |Added Status|NEW |RESOLVED CC| |jakub at gcc dot gnu.org Resolution| |FIXED --- Comment #28 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-24 17:21:21 UTC --- Fixed. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug bootstrap/50156] in-tree CLooG is not picked up by toplevel configure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50156 --- Comment #2 from Ruben Van Boxem vanboxem.ruben at gmail dot com 2011-08-24 19:26:55 UTC --- Created attachment 25090 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25090 Patch to allow a non-bootstrap compiler to build with in tree prereqs for graphite Attached is a full patch (including manual changes to generated files) that allow for in-tree CLooG (isl) to be used to build a GCC with Graphite. This patch was made against GCC 4.6 (SVN) and should apply cleanly for testing purposes. I have not ported the configure bit for CLooG to configure.ac, the rest (in configure and makefile.in) should be matched by makefile.def and configure.ac changes.
[Bug c/18624] GCC does not detect local variable set but never used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18624 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0 --- Comment #30 from Andrew Pinski pinskia at gcc dot gnu.org 2011-08-24 19:26:17 UTC --- (In reply to comment #29) Dear Jakub, I just did try the example code with gcc 4.5.2. It plain c not c++. Some oldfashioned people still use c ;) It was added for 4.6.0.
[Bug debug/49864] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2439
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49864 --- Comment #9 from Richard Henderson rth at gcc dot gnu.org 2011-08-24 19:35:31 UTC --- Created attachment 25091 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25091 followup patch I think you'd have been better off opening a new bug. That said, the cross-jumping code needs a bit more restriction to prevent the introduction of a region with inconsistent stack depth. This works for the given test case, anyway.
[Bug rtl-optimization/50180] New: insn does not satisfy constraints for 444.namd when generating profile data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50180
Bug #: 50180
Summary: insn does not satisfy constraints for 444.namd when
generating profile data
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wschm...@gcc.gnu.org
CC: berg...@gcc.gnu.org, meiss...@gcc.gnu.org,
pthau...@gcc.gnu.org
Host: powerpc64-linux
Target: powerpc64-linux
Build: powerpc64-linux
Created attachment 25092
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25092
Reduced test case
The following occurs on powerpc64-linux in gcc-4_6-branch and
ibm/gcc-4_6-branch, but not on trunk. The options listed are the minimum
required to exhibit the bug. The reduced test case is attached.
/home/wschmidt/gcc/install/gcc-4_6-branch/libexec/gcc/powerpc64-linux/4.6.2/cc1plus
-mcpu=power7 -m32 -O3 -fprofile-generate -ffast-math -fpeel-loops
ComputeNonbondedUtil-min-indent.ii
Index Molecule::atomvdwtype(int) const ExclusionCheck*
Molecule::get_excl_check_for_atom(int) const const LJTable::TableEntry*
LJTable::table_row(unsigned int) const static void
ComputeNonbondedUtil::calc_pair_energy_fullelect(nonbonded*)
Analyzing compilation unit
Performing interprocedural optimizations
*free_lang_data visibility early_local_cleanups tree_profile_ipa
increase_alignment whole-program ipa-profile cp inline pure-const
static-varAssembling functions:
static void ComputeNonbondedUtil::calc_pair_energy_fullelect(nonbonded*)
ComputeNonbondedUtil-min-indent.ii: In static member function ‘static void
ComputeNonbondedUtil::calc_pair_energy_fullelect(nonbonded*)’:
ComputeNonbondedUtil-min-indent.ii:421:1: error: insn does not satisfy its
constraints:
(insn 2590 1849 1850 39 (set (mem/c:DI (plus:SI (reg/f:SI 1 1)
(const_int 32760 [0x7ff8])) [14 %sfp+32760 S8 A64])
(reg:DI 20 20)) ComputeNonbondedUtil-min-indent.ii:206 403
{*movdi_internal32}
(nil))
ComputeNonbondedUtil-min-indent.ii:421:1: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:403
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug bootstrap/50156] in-tree CLooG is not picked up by toplevel configure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50156 Ruben Van Boxem vanboxem.ruben at gmail dot com changed: What|Removed |Added Attachment #25090|0 |1 is obsolete|| --- Comment #3 from Ruben Van Boxem vanboxem.ruben at gmail dot com 2011-08-24 20:15:20 UTC --- Created attachment 25093 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25093 Patch to allow a non-bootstrap compiler to build with in tree prereqs for graphite Corrected small issues with ppl-watchdog (enabled it regardless for an intree build; this would break an out-of tree ppl without libpwl though: it's hacky) The problem is that in-tree ppl should be configured with --disable-watchdog if $enable_watchdog is not requested.
[Bug c/48418] [4.5/4.6/4.7 Regression] Bit shift operator =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48418 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Priority|P2 |P3 CC||rguenth at gcc dot gnu.org --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org 2011-08-24 20:47:06 UTC --- Richard, can you explain why this is a P2? the warning is only a regression in the sense we would warn about about one case but not any more and the code is undefined at runtime which means we should warn about it in all cases but currently don't.
[Bug gcov-profile/38292] [4.4/4.5/4.6/4.7 Regression] corrupted profile info with -O[23] -fprofile-use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38292 --- Comment #18 from Andrew Pinski pinskia at gcc dot gnu.org 2011-08-24 20:50:52 UTC --- I don't think this is a regression now as we never had good thread support for gcov/profiling. That is we don't do atomic adds for the profiling.
[Bug rtl-optimization/50181] New: insn does not satisfy constraints for 481.wrf when generating profile data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50181
Bug #: 50181
Summary: insn does not satisfy constraints for 481.wrf when
generating profile data
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wschm...@gcc.gnu.org
CC: berg...@gcc.gnu.org, meiss...@gcc.gnu.org,
pthau...@gcc.gnu.org
Host: powerpc64-linux
Target: powerpc64-linux
Build: powerpc64-linux
Created attachment 25094
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25094
Reduced test case
The following occurs on powerpc64-linux in gcc-4_6-branch and
ibm/gcc-4_6-branch, but not on trunk. The options listed are the minimum
required to exhibit the bug. The reduced test case is attached.
/home/wschmidt/gcc/install/gcc-4_6-branch/libexec/gcc/powerpc64-linux/4.6.2/f951
-mcpu=power7 -O3 -fprofile-generate wrf_io-min.f90
reorder transpose fieldio netcdf_err uppercase lowercase extorderstr extorder
getindices getdim gettimeindex getname datecheck getdh allochandle
ext_ncd_read_field
Analyzing compilation unit
Performing interprocedural optimizations
*free_lang_data visibility early_local_cleanups tree_profile_ipa
increase_alignment whole-program ipa-profile cp inline pure-const
static-varAssembling functions:
allochandle getdh datecheck getname gettimeindex getdim getindices extorder
extorderstr lowercase uppercase netcdf_err fieldio transpose reorder
ext_ncd_read_field
wrf_io-min.f90: In function ‘ext_ncd_read_field’:
wrf_io-min.f90:184:0: error: insn does not satisfy its constraints:
(insn 451 320 450 8 (set (reg:V4SI 7 7)
(const_vector:V4SI [
(const_int 1 [0x1])
(const_int 1 [0x1])
(const_int 1 [0x1])
(const_int 1 [0x1])
])) wrf_io-min.f90:176 793 {*vsx_movv4si}
(nil))
wrf_io-min.f90:184:0: internal compiler error: in reload_cse_simplify_operands,
at postreload.c:403
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug c/50154] attribute printf and scanf should imply attribute nonnull
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50154 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Severity|normal |enhancement --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-08-24 21:15:37 UTC --- I think it is better if the person adds nonnull attribute themselves rather than GCC adding it with the printf format.
[Bug bootstrap/50148] GCC fails to bootstrap with -O3 due to may be used uninitialized errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50148 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-08-24 21:17:24 UTC --- (In reply to comment #1) (Another solution would be to build GCC with -Wno-error=maybe-uninitialized.) I think that is a bad idea really. The question is this is a false positive or a true positive?
[Bug c++/50182] New: Performance degradation from gcc 4.1 (x86_64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182 Bug #: 50182 Summary: Performance degradation from gcc 4.1 (x86_64) Classification: Unclassified Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: oleg.smol...@gmail.com G++ 4.6 emits slower code based on the following set of benchmarks: http://stlab.adobe.com/performance/ The discussion thread is here: http://gcc.gnu.org/ml/gcc/2011-07/threads.html#00506 http://gcc.gnu.org/ml/gcc/2011-08/threads.html#00411 I digested one of the tests down to a single short case (see attachments): http://gcc.gnu.org/ml/gcc/2011-08/msg00391.html g++ 4.1 (1.35 sec, 1185M ops/s): .text:00400FE0 loc_400FE0: .text:00400FE0 movzx eax, ds:data8[rdx] .text:00400FE7 add rdx, 1 .text:00400FEB add eax, 0Ah .text:00400FEE cmp rdx, 1F40h .text:00400FF5 lea ecx, [rax+rcx] .text:00400FF8 jnz short loc_400FE0 g++ 4.6 (2.86s, 563M ops/s) : .text:00400D90 loc_400D90: .text:00400D90 add eax, 0Ah .text:00400D93 add al, [rdx] .text:00400D95 add rdx, 1 .text:00400D99 cmp rdx, 503480h .text:00400DA0 jnz short loc_400D90 P.S. setting the component to C++. Optimizer?
[Bug target/50068] Invalid memory access in incr_ticks_for_insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50068 --- Comment #7 from Valeriy E. Ushakov uwe at netbsd dot org 2011-08-24 21:26:23 UTC --- This fixes the problem. Thanks.
[Bug tree-optimization/50183] New: ICE in verify_ssa for 416.gamess when optimizing using profile data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50183
Bug #: 50183
Summary: ICE in verify_ssa for 416.gamess when optimizing using
profile data
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wschm...@gcc.gnu.org
CC: berg...@gcc.gnu.org
Host: powerpc64-linux
Target: powerpc64-linux
Build: powerpc64-linux
Created attachment 25095
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25095
Test case
The following occurs on powerpc64-linux in gcc-4_6-branch and
ibm/gcc-4_6-branch, but not on trunk. The options listed are the minimum
required to exhibit the bug. The full test case is attached, together with the
profile data. Because profile data contains location information, reducing the
test case isn't practical.
/home/wschmidt/gcc/install/gcc-4_6-branch/libexec/gcc/powerpc64-linux/4.6.2/f951
-O3 -fprofile-use -ffast-math -floop-interchange grd2c.fppized.f
grd2c.fppized.f:1105.21:
CALL JKGNMV(GNM,NUMG*NROOTS*3,NMAX,MMAX,
1
Warning: Type mismatch in argument 'gnm' at (1); passed REAL(8) to REAL(4)
grd2c.fppized.f:1116.21:
CALL JKXYZV(GIJKL,GIJKL,GNKL,GNKL,GNKL,GNM,GNM,
1
Warning: Type mismatch in argument 'gijkl' at (1); passed REAL(8) to REAL(4)
grd2c.fppized.f:1129.21:
CALL JDXYZV(GIJKL,GIJKL,GIJKL,GIJKL,GIJKL,GIJKL,GIJKL,GIJKL,
1
Warning: Type mismatch in argument 'gi' at (1); passed REAL(8) to REAL(4)
grd2c.fppized.f:1150.33:
CALL DSPDFV(NUMG,NROOTS,IJKLG,GINT,FINT,SINT,GIJKL,
1
Warning: Rank mismatch in argument 'ijklg' at (1) (scalar and rank-2)
jkdout jkdinv dspdfv dspdfs jkdzer jdxyzv jdxyzs jkxyzv spec_jkxyzs jkgnmv
jkgnms jkbcdf jkwrys jkdspd jkxyzs
Analyzing compilation unit
Performing interprocedural optimizations
*free_lang_data visibility early_local_cleanups {GC 5613k - 3437k} {GC
5396k - 4027k} tree_profile_ipa increase_alignment whole-program
ipa-profile cp inline pure-const static-varAssembling functions:
jkdout
grd2c.fppized.f: In function ‘jkdout’:
grd2c.fppized.f:784:0: error: missing definition
for SSA_NAME: err2.395_561 in statement:
err2_lsm.820_574 = PHI err2.395_561(73)
PHI argument
err2.395_561
for PHI node
err2_lsm.820_574 = PHI err2.395_561(73)
grd2c.fppized.f:784:0: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug tree-optimization/50183] ICE in verify_ssa for 416.gamess when optimizing using profile data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50183 --- Comment #1 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-08-24 21:32:34 UTC --- Created attachment 25096 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25096 Profile data for grd2c.fppized.f
[Bug bootstrap/50148] GCC fails to bootstrap with -O3 due to may be used uninitialized errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50148 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2011-08-24 21:33:23 UTC --- (In reply to comment #0) Created attachment 25070 [details] Patch for c-parser.c Error message: ../../gcc-4.7/gcc/c-parser.c: In function 'c_expr c_parser_postfix_expression_after_primary(c_parser*, location_t, c_expr)': ../../gcc-4.7/gcc/c-parser.c:6664:16: error: 'origtypes' may be used uninitialized in this function [-Werror=maybe-uninitialized] This patch is correct and does prevent the warning as we are using an uninitialized value of origtypes (though if we inline build_function_call_vec and then convert_arguments, the only time it is used unitialized is when exprlist is non NULL but that requires a lot of optimizations to happen really and it might only be seen by the human eye rather the compiler).
[Bug target/45074] GCC Segmentation fault - negating global register variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45074 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.6.0 Resolution||FIXED Target Milestone|--- |4.7.0 Severity|critical|normal --- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org 2011-08-24 22:09:48 UTC --- Fixed so closing as such.
[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182 --- Comment #1 from Oleg Smolsky oleg.smolsky at gmail dot com 2011-08-24 22:13:26 UTC --- Created attachment 25097 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25097 The test case This is the preprocessed source for the test discussed in the mail thread.
[Bug other/32415] libgcc_s not found in library search path with --enable-version-specific-runtime-libs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32415 Harald van Dijk harald at gigawatt dot nl changed: What|Removed |Added CC||harald at gigawatt dot nl --- Comment #11 from Harald van Dijk harald at gigawatt dot nl 2011-08-24 22:29:36 UTC --- (In reply to comment #8) In ./gcc/libgcc.mvars, we have SHLIB_INSTALL = $(mkinstalldirs) $(DESTDIR)$(slibdir)@shlib_slibdir_qual@; [...] where $(DESTDIR)$(libdir) seems to be correct for me. However, the last part (@shlib_slibdir_qual@) is substituted in libgcc/Makefile.in(install-shared) with $(MULTIOSSUBDIR) which is based on `$(CC) $(CFLAGS) -print-multi-os-directory)`, here '../lib64'. Yes, for --enable-version-specific-runtime-libs, it should be replaced by $(MULTISUBDIR) rather than $(MULTIOSSUBDIR). But $(MULTISUBDIR) would be wrong for the default configuration. Other subdirectories handle this by adding the $(MULTI*) from the configure script instead of the Makefile.in.
[Bug target/39725] [4.5/4.6/4.7 Regression][cond-optab] MIPS pessimizations on floating-point
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39725 --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org 2011-08-24 22:28:52 UTC --- for compare-fp-1: iuneq same ieq improved (using movf) iltgt have to look more into (since I am comparing 4.3 vs 4.6) ine same iunlt improved (using movf) ilt improved (using movf) ile improved (using movf) iungt improved (using movf) igt improved (using movf) iunge improved (using movf) ige have to look more into (since I am comparing 4.3 vs 4.6) I noticed that these all could be improved even more by using movf more and better jump threading.
[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182 davidxl xinliangli at gmail dot com changed: What|Removed |Added CC||xinliangli at gmail dot com --- Comment #2 from davidxl xinliangli at gmail dot com 2011-08-24 23:15:44 UTC --- The problem is fixed in trunk compiler: 1) with 4.6 compiler: test description absolute operations ratio with number time per second test0 0 int8_t constant add 3.29 sec 486.32 M 1.00 RAT_STALLS.registers = 288249 (sampling count 10001) 2) with trunk compiler: test description absolute operations ratio with number time per second test0 0 int8_t constant add 1.34 sec 1194.03 M 1.00 No partial register stalls from user functions. Inner loop from trunk compiler: .L55: movzbl0(%rbp,%rcx), %r9d addq$1, %rcx cmpl%ecx, %ebx leal10(%r8,%r9), %r8d jg.L55 Inner loop from 46 compiler: .L43: addl$10, %eax addb(%rdx), %al addq$1, %rdx cmpq$data8+8000, %rdx jne.L43 RAT stalls (not precise event so the instruction causing stalls is a little off) : 400e27:nopw 0x0(%rax,%rax,1) 127 0.0440 : 400e30:add$0xa,%eax 5869 2.0330 : 400e33:add(%rdx),%al 282125 97.7263 : 400e35:add$0x1,%rdx : 400e39:cmp$0x404560,%rdx : 400e40:jne400e30 main+0xd0 David
[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182 --- Comment #3 from davidxl xinliangli at gmail dot com 2011-08-25 00:13:00 UTC --- Caused by differences in FE generated code: 46: D.6887 = (int) D.6886; D.6888 = custom_constant_addsigned char::do_shift (D.6887); D.6889 = (unsigned char) D.6888; result.8 = (unsigned char) result; D.6891 = D.6889 + result.8; result = (signed char) D.6891; n = n + 1; trunk: D.6938 = (int) D.6937; D.6874 = custom_constant_addsigned char::do_shift (D.6938); D.6939 = (int) result; -- promoted to int D.6940 = (int) D.6874; ---promoted to int D.6941 = D.6939 + D.6940; result = (signed char) D.6941; n = n + 1;
[Bug rtl-optimization/48721] [4.6/4.7 Regression] ICE: verify_flow_info failed: missing barrier after block 6 with -foptimize-sibling-calls -fsched2-use-superblocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48721 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Known to work|4.7.0 | Summary|[4.6 Regression] ICE: |[4.6/4.7 Regression] ICE: |verify_flow_info failed:|verify_flow_info failed: |missing barrier after block |missing barrier after block |6 with |6 with |-foptimize-sibling-calls|-foptimize-sibling-calls |-fsched2-use-superblocks|-fsched2-use-superblocks Known to fail||4.7.0 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2011-08-25 00:52:24 UTC --- Fails for me with 4.7.0 20110823 (experimental) [trunk revision 178018] (x86_64-unknown-linux-gnu). gcc -O -foptimize-sibling-calls -fsched2-use-superblocks -fschedule-insns2 -mtune=core2 t.c Note the tune at the end.
[Bug rtl-optimization/48721] [4.6/4.7 Regression] ICE: verify_flow_info failed: missing barrier after block 6 with -foptimize-sibling-calls -fsched2-use-superblocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48721 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-08-25 Ever Confirmed|0 |1
[Bug rtl-optimization/48721] [4.6/4.7 Regression] ICE: verify_flow_info failed: missing barrier after block 6 with -foptimize-sibling-calls -fsched2-use-superblocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48721 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2011-08-25 01:39:51 UTC --- begin_move_insn is not creating the needed barrier.
[Bug debug/50132] [4.7 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2234 with -fno-asynchronous-unwind-tables and long double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50132 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-08-25 CC||rth at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-08-25 01:46:36 UTC --- Confirmed.
[Bug c++/50114] ICE on invalid code in pop_binding, at cp/name-lookup.c:382
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50114 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2011-08-25 01:49:51 UTC --- Reducing.
[Bug c++/50114] ICE with declaration inside for statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50114
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Keywords|diagnostic |ice-on-valid-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2011-08-25
CC||jason at gcc dot gnu.org
Summary|ICE on invalid code in |ICE with declaration inside
|pop_binding, at |for statement
|cp/name-lookup.c:382|
Ever Confirmed|0 |1
--- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2011-08-25
02:00:47 UTC ---
Here is one which is an ICE on valid code:
int open()
{
int *x2feed_i = 0;
auto insert_feed = [](unsigned char venue, int* newfeed)
{
for(int x2feed_i = 1; 0; ) ;
x2feed_i = newfeed;
}
}
The only reason why the original was invalid was the invalid use of x2feed_i
inside the loop as I think the int should have been auto.
[Bug debug/50132] [4.7 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2234 with -fno-asynchronous-unwind-tables and long double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50132 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rth at gcc dot gnu.org |gnu.org | --- Comment #2 from Richard Henderson rth at gcc dot gnu.org 2011-08-25 03:03:11 UTC --- Mine.
[Bug c++/49045] [C++0x] unexpected different exception specifier error with noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49045 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from Jason Merrill jason at gcc dot gnu.org 2011-08-25 05:08:46 UTC --- Fixed as per core decision in Bloomington.
