[Bug middle-end/32602] New: Sibcall optimization fails to detect overlap
The following program returns an incorrect result when compiled for
arm-none-elf at -O2:
~~
typedef struct {
int data[4];
} arr16_t;
int result = 0;
void func2(int i, int j, arr16_t arr)
{
result = (arr.data[0] != 1
|| arr.data[1] != 2
|| arr.data[2] != 3
|| arr.data[3] != 4);
}
void func1(int i, int j, int k, arr16_t a)
{
func2(i, j, a);
}
int main(int argc, const char *argv[])
{
arr16_t arr = {{1, 2, 3, 4}};
func1(0, 0, 0, arr);
return result;
}
~~
It should exit with 0, but instead exits with 1.
--
Summary: Sibcall optimization fails to detect overlap
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jconner at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32602
[Bug middle-end/32602] Sibcall optimization fails to detect overlap
--- Comment #1 from jconner at apple dot com 2007-07-02 23:19 --- The problem is that the sibcall optimization incorrectly believes that the incoming arr16_t parameter to func1 is located at the same location on the stack as the outgoing arr16_t parameter to func2, and so incorrectly allows a sibcall to occur. I have a patch for this that I will submit shortly. -- jconner at apple dot com changed: What|Removed |Added CC||jconner at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32602
[Bug middle-end/32603] New: Sibcall optimization fails to detect non-overlapping arguments
The following code, compiled for arm-none-elf at -O2:
~~
#define noinline __attribute__((noinline))
typedef struct {
int data[4];
} arr16_t;
int result = 0;
void noinline func2 (int i, int j, arr16_t arr)
{
result = (arr.data[0] != 1
|| arr.data[1] != 2
|| arr.data[2] != 3
|| arr.data[3] != 4);
}
void func1 (int i, int j, int k, int l, int m, int n, arr16_t a)
{
func2(i, j, a);
}
int main(int argc, const char *argv[])
{
arr16_t arr = {{1, 2, 3, 4}};
func1(0, 0, 0, 0, 0, 0, arr);
return result;
}
~~
The call to func2 should be optimized into a sibcall, however store_one_arg()
is preventing it because it incorrectly identifies the arr16_t coming into
func1 as overlapping on the stack where it needs to put the outgoing arr16_t
for the call to func2. In fact, the incoming arg only uses [SP,SP+7] (the
other two words are passed in registers) and the outgoing arg uses
[SP+8,SP+23].
--
Summary: Sibcall optimization fails to detect non-overlapping
arguments
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jconner at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32603
[Bug middle-end/32603] Sibcall optimization fails to detect non-overlapping arguments
--- Comment #1 from jconner at apple dot com 2007-07-02 23:28 --- I have a patch which addresses this (and pr32602) -- I will submit it shortly. -- jconner at apple dot com changed: What|Removed |Added CC||jconner at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32603
[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list
--- Comment #7 from jconner at apple dot com 2007-06-13 17:09 --- (In reply to comment #6) I see that PR25505 caused a bunch of code generation regressions. On i?86, with -O2 -m32: ... When you say regressions, I assume you mean size/performance, not correctness, right? If so, that's to be expected, as the previous tree-nrv implementation was being overly permissive, and the new implementation is conservatively pessimistic, as the comments indicate. If I have introduced anything incorrect, please let me know and I'd be glad to take a look. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32285
[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list
--- Comment #2 from jconner at apple dot com 2007-06-11 16:06 --- (In reply to comment #1) Looking at http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00951.html I'm slightly worried about backporting this to gcc-4_1-branch though. Has that been resolved? I recall being told that the problem was most likely the benchmarks, and that I shouldn't worry about it. Unfortunately, it must have been off-list, because I can't find anything in the email archives. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32285
[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list
--- Comment #4 from jconner at apple dot com 2007-06-11 18:59 --- Sorry, yes, reading back I wasn't being very clear. I meant to say that the impression I was left with was that it wasn't a result of my change, but of the test environment, an idea which was supported by my own benchmarking results. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32285
[Bug middle-end/30196] VLA and setjumplongjump exceptions
--- Comment #2 from jconner at apple dot com 2007-03-13 23:55 --- I have a patch for this that I'm testing right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30196
[Bug middle-end/29683] [4.1/4.2 Regression] Arg split between stack/regs can cause stack corruption
--- Comment #10 from jconner at apple dot com 2007-01-29 17:11 --- Same fix that was applied to mainline resolved the issue in 4.1 and 4.2 branches. Checked in to both of those branches. -- jconner at apple dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29683
[Bug middle-end/29683] [4.1/4.2 Regression] Arg split between stack/regs can cause stack corruption
--- Comment #4 from jconner at apple dot com 2007-01-25 17:11 --- I'll investigate fixing this in the 4.1 and 4.2 branches, as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29683
[Bug target/30485] New: ICE in rs6000_emit_vector_compare when building with -fno-trapping-math
The tests pr23816-1.c and vect-111.c (from gcc.dg/vect) generate an ICE when compiled with -fno-trapping-math for rs6000: $ gcc pr23816-1.c -fno-trapping-math -ftree-vectorize -maltivec -O2 pr23816-1.c: In function 'foo': pr23816-1.c:9: internal compiler error: in rs6000_emit_vector_compare, at config/rs6000/rs6000.c:11962 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. $ gcc vect-111.c -fno-trapping-math -ftree-vectorize -maltivec -O2 vect-111.c: In function 'main1': vect-111.c:19: internal compiler error: in rs6000_emit_vector_compare, at config/rs6000/rs6000.c:11962 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. $ I have a patch for this that I'll submit... -- Summary: ICE in rs6000_emit_vector_compare when building with - fno-trapping-math Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jconner at apple dot com GCC host triplet: powerpc-apple-darwin8 GCC target triplet: powerpc-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30485
[Bug middle-end/29683] New: Arg split between stack/regs can cause stack corruption
On targets which allow a function argument to be split between registers and
the stack, values can be corrupted by later function calls.
Specifically - this code:
~~
/* { dg-do run } */
/* { dg-options -Os -fno-inline-functions } */
void abort (void);
typedef struct {
int x[7];
} agg7;
typedef struct {
int mbr1;
int mbr2;
} agg2;
int expected = 31415;
agg7 filler;
int GetConst (agg7 filler, agg2 split)
{
return expected;
}
void VerifyValues (agg7 filler, int last_reg, int first_stack, int
second_stack)
{
if (first_stack != 123 || second_stack != expected)
abort ();
}
void RunTest (agg2 a)
{
int result;
result = GetConst (filler, a);
VerifyValues (filler, 0, a.mbr1, result);
}
int main(void)
{
agg2 result = {123, 456};
RunTest (result);
return 0;
}
~~
compiled with gcc -O1 incorrectly aborts.
--
Summary: Arg split between stack/regs can cause stack corruption
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jconner at apple dot com
GCC host triplet: powerpc-apple-darwin8
GCC target triplet: powerpc-apple-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29683
[Bug middle-end/29683] Arg split between stack/regs can cause stack corruption
--- Comment #1 from jconner at apple dot com 2006-11-01 19:11 --- What's happening is that TER is inserting the call to GetConst in place of 'result' in the call to VerifyValues, as such: (pre-TER) result_4 = GetConst (filler, a); VerifyValues (filler, 0, a$mbr1_5, result_4); (post-TER) VerifyValues (filler, 0, a$mbr1, GetConst (filler, a)); While this itself isn't a problem, it exposes a problem in the argument handling mechanism where an argument split between regs/stack doesn't correctly detect collision with other in-use stack locations. I believe this is a problem on platforms that ACCUMULATE_OUTGOING_ARGS. I have a patch I'll send out for consideration. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29683
[Bug target/25376] section attribute doesn't work on darwin
--- Comment #7 from jconner at apple dot com 2006-10-02 16:44 --- (In reply to comment #6) Shouldn't this bug be marked as closed now? Perhaps - however, it's not been fixed on the 4.0 or 4.1 branches... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25376
[Bug middle-end/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code
--- Comment #17 from jconner at apple dot com 2006-08-21 23:43 --- I can reduce the stack size in this example to ~13k by not invoking mark_temp_addr_taken from expand_call (calls.c). This allows compiler-generated temps used to store return values to share stack slots, even when the function calls are in the same scope. The validity of this change is supported by testing against i386-Linux and ppc-Darwin on 4.1 and mainline with no regressions, but the original importer of this code has some concerns that this might introduce subtle problems. See discussion here: http://gcc.gnu.org/ml/gcc/2006-08/msg00389.html -- jconner at apple dot com changed: What|Removed |Added CC||jconner at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
[Bug target/26262] New: Named section support should infer segment name
The cctools assembler used by powerpc-apple-darwin requires section directives
in the form:
.section SEGNAME, SECTION_NAME
And, using a section attribute in gcc passes the name along unmodified. So,
for example:
void foo (void) __attribute__((section(bar)));
void foo (void) {}
produces:
.section bar
...
which generates an assembly-time syntax error. It would be nice if gcc would
infer the segment name from the data type (__TEXT for functions and __DATA for
data), unless a segment name is present (as indicated by a comma in the section
name specification, perhaps?)
There is some discussion of this in the thread starting here:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00226.html
--
Summary: Named section support should infer segment name
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jconner at apple dot com
GCC target triplet: powerpc-apple-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26262
[Bug target/25376] New: section attribute doesn't work on darwin
Trying to assign a function to a user-named section fails on darwin in the 4.0,
4.1, and mainline. For example, compiling this code:
void specialfn (void) __attribute__((section (__TEXT,__init)));
void specialfn (void) {}
Places the function 'specialfn' into the default .text section instead of the
user-specified __init section. From the assembly code:
.text
.align 2
.globl _specialfn
_specialfn:
Should be:
.section __TEXT,__init
.align 2
.globl _specialfn
_specialfn:
--
Summary: section attribute doesn't work on darwin
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jconner at apple dot com
GCC target triplet: powerpc-apple-darwin8.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25376
[Bug target/25376] section attribute doesn't work on darwin
--- Comment #1 from jconner at apple dot com 2005-12-12 18:11 --- I have a patch for this I'll submit to gcc-patches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25376
[Bug c++/24663] New: Template instantiation generating a zero-sized array doesn't fail
The following compliant code fails to compile: templateint I int f1 (char[I]); templateint I int f1 (char p1 = I); int i = f10(0); .. instead it generates an error, e.g.: test.C:3: error: call of overloaded 'f1(int)' is ambiguous test.C:1: note: candidates are: int f1(char*) [with int I = 0] test.C:2: note: int f1(char) [with int I = 0] The first template should fail to match (SFINAE) because doing so would cause a reference to a zero-sized array (as per ISO C++ section 14.8.2.2). It is possible that gcc may be performing the type[size] -- type * conversion too early, as prohibited by 14.8.2.3: After this substitution is performed, the function parameter type adjustments described in 8.3.5 are performed. [Example: A parameter type of void ()(const int, int[5]) becomes void(*)(int,int*). -- Summary: Template instantiation generating a zero-sized array doesn't fail Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jconner at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24663
[Bug c++/24664] New: Template instantiation generating an array of voids doesn't fail
The following code, pulled from an example in section 14.8.2.2 of ISO C++, should fail to compile, but doesn't: templateclass T int f(T[5]); int j=fvoid(0); A function template instantiation should fail if it would create an array with void elements. -- Summary: Template instantiation generating an array of voids doesn't fail Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jconner at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24664
[Bug c++/22153] [3.4/4.0/4.1 regression] ICE on invalid template specialization
--- Comment #2 from jconner at apple dot com 2005-10-11 17:31 --- Patch submitted here: http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01274.html Awaiting review... -- jconner at apple dot com changed: What|Removed |Added CC||jconner at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22153
[Bug c++/23708] New: Non-inline function incorrectly treated as inline when using precompiled headers
The non-inline specialization of an inline member function of a template class
is not being treated as
inline when using precompiled headers.
For example, consider
test.H:
template class T class simple_class {
public:
inline void testfn (T);
};
test.C:
#include test.H
template void simple_classint::testfn (int) {}
int main (int argc, char *argv[])
{
simple_classint sc1;
sc1.testfn (5);
}
When compiled without precompiled headers, the function appears a simple global
function:
.global _ZN12simple_classIiE6testfnEi
But when test.H is first compiled (with g++ test.H) into a PCH, and then
test.C is compiled, the
function appears as a weak symbol in a COMDAT section, implying that g++ is
considering the
specialization inline even though it isn't marked as such.
.section.text._ZN12simple_classIiE6testfnEi,axG,%
progbits,_ZN12simple_classIiE6testfnEi,comdat
.align 2
.weak _ZN12simple_classIiE6testfnEi
.type _ZN12simple_classIiE6testfnEi, %function
--
Summary: Non-inline function incorrectly treated as inline when
using precompiled headers
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jconner at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: arm-none-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23708
[Bug c++/23708] Non-inline function incorrectly treated as inline when using precompiled headers
--- Additional Comments From jconner at apple dot com 2005-09-03 02:09 --- When generating a precompiled header, finish_member_declaration() invokes note_decl_for_pch() for the function testfnT, and assigns it to the COMDAT section with weak linkage. Then, when the test.C file is compiled, a function testfnint (implicit declaration) is generated, and inherits the COMDAT properties of testfnT. Finally, when the explicit specialization is actually seen, the function duplicate_decls() attempts to merge the declarations, and assigns the specialization function (incorrectly) to the COMDAT section. When not using precompiled headers, the testfnT function is not assigned to the COMDAT section until after its attributes are merged with the specialization by duplicate_decls(), and since checks are already in place to make sure that the specialization doesn't inherit the DECL_DECLARED_INLINE_P attribute (which is a prerequesite for ending up in COMDAT), both decls are assigned to the correct sections. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23708
[Bug middle-end/23584] New: ipa-pure-const pass ignores dereferencing a volatile pointer type
A function that dereferences an absolute address in memory, e.g.:
int test (void)
{
return * (volatile int *) 0x1234;
}
Is incorrectly identified by the ipa-pure-const pass as being pure, resulting
in invalid optimizations
being performed.
This can be seen in the ipa-pure-const dump file:
Function found to be pure: test
--
Summary: ipa-pure-const pass ignores dereferencing a volatile
pointer type
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jconner at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23584
[Bug middle-end/23237] [4.1 Regression] -O1 rejects valid code (xxx causes a section type conflict).
--- Additional Comments From jconner at apple dot com 2005-08-24 16:17 --- The declaration of the variable actions (in the given example) is being changed to READONLY by the ipa- reference pass (in function static_execute), so when it comes time to create the section in named_section, the default flags do not include SECTION_WRITE, and so they conflict with the flags for the variable message, producing the error message. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23237
[Bug middle-end/23237] [4.1 Regression] -O1 rejects valid code (xxx causes a section type conflict).
--- Additional Comments From jconner at apple dot com 2005-08-24 17:04 --- It seems like TREE_CONSTANT has the semantics we're looking for (value doesn't change) instead of TREE_READONLY, but I think someone more familiar with this pass (perhaps the author, Kenneth Zadeck?) would have to make that judgement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23237
[Bug middle-end/23237] [4.1 Regression] -O1 rejects valid code (xxx causes a section type conflict).
--- Additional Comments From jconner at apple dot com 2005-08-24 17:24 --- (In reply to comment #8) Actually TREE_READONLY is correct and TREE_CONSTANT is incorrect to use this context (there was a discussion about this before but I cannot find it). TREE_CONSTANT is not set by the way on static const variables in C anyways, only TREE_READONLY. Your second sentence is consistent with my (admittedly naive) understanding - that TREE_READONLY represents whether the value is declared constant, and TREE_READONLY represents whether the value actually changes. Sorry if this has been hashed out already - I thought I would put down what I've seen in case it hadn't been looked into yet. I'll search the web archives to see if I can find that previous discussion. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23237
[Bug middle-end/23241] [3.4/4.0/4.1 Regression] Invalid code generated for comparison of uchar to 255
--- Additional Comments From jconner at apple dot com 2005-08-05 16:14 --- Subject: Re: [3.4/4.0/4.1 Regression] Invalid code generated for comparison of uchar to 255 Right. The annoying thing is that it is in 3.3.6 too so I think someone should fix the typo on the 3.3 branch too. Will do. Thanks for pointing that out - I would have missed it otherwise! - Josh -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23241
[Bug middle-end/23241] New: Invalid code generated for comparison of uchar to 255
The following test code incorrectly generates an assertion failure on gcc
mainline and 4.0.1:
#include assert.h
struct fbs {
unsigned char uc8;
} fbs1 = {255};
void testfn ( struct fbs *fbs_ptr )
{
if ((fbs_ptr-uc8 != 255) (fbs_ptr-uc8 != 0))
assert(0);
}
int main (int argc, char *argv[])
{
testfn (fbs1);
return 0;
}
--
Summary: Invalid code generated for comparison of uchar to 255
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jconner at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin8.2.0
GCC host triplet: powerpc-apple-darwin8.2.0
GCC target triplet: arm-none-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23241
[Bug middle-end/23241] Invalid code generated for comparison of uchar to 255
-- What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23241
[Bug middle-end/23241] Invalid code generated for comparison of uchar to 255
--- Additional Comments From jconner at apple dot com 2005-08-05 00:17 --- I believe I have tracked down the root of this behavior to an invalid transformation in simplify_comparison (from combine.c). See email thread starting here: http://gcc.gnu.org/ml/gcc/2005-08/msg00159.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23241
[Bug c++/21971] New: class friend declaration doesn't allow use in class scope
The following code:
class a {
friend class b;
b *pb;
};
Produces an error message in the current mainline (4.1.0 development):
bar.c:3: error: ISO C++ forbids declaration of 'b' with no type
bar.c:3: error: expected ';' before '*' token
14882:2003, 11.4.7, indicates that this should be allowed:
A name nominated by a friend declaration shall be accessible in the scope of
the class containing the
friend declaration.
This is a regression from 4.0.
--
Summary: class friend declaration doesn't allow use in class
scope
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jconner at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21971
[Bug middle-end/21648] New: ICE on code with nested loops
Compiling the following code with -O2 causes an ICE (verified on both
i686-pc-cygwin and arm-none-
elf):
struct mad_bitptr {
unsigned char const *byte;
};
struct mad_stream {
struct mad_bitptr ptr;
};
struct channel {
unsigned short part2_3_length;
};
struct granule {
struct channel ch[2];
};
struct sideinfo {
struct granule gr[2];
};
static
void III_sideinfo(struct mad_bitptr *ptr, struct sideinfo *si)
{
unsigned int ngr, gr, ch;
unsigned int nch;
for (gr = 0; gr ngr; ++gr) {
struct granule *granule = si-gr[gr];
for (ch = 0; ch nch; ++ch) {
struct channel *channel = granule-ch[ch];
channel-part2_3_length = 1;
}
}
}
void mad_layer_III(struct mad_stream *stream)
{
struct sideinfo si;
III_sideinfo(stream-ptr, si);
}
This happens in the mainline, and appears to be the result of one of the
patches applied 2005-05-17,
as it doesn't happen in a snapshot from the previous day.
A segfault is occurring when the function is_gimple_val (from tree-gimple.c)
passes a NULL value to
is_gimple_reg_type().
--
Summary: ICE on code with nested loops
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jconner at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21648
[Bug middle-end/21648] ICE on code with nested loops
-- What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21648
[Bug target/21128] Returning vector 32-bits or larger generates ICE
--- Additional Comments From jconner at apple dot com 2005-05-17 21:50 --- Patch committed to mainline on 13 May 2005. -- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||05/msg01302.html Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21128
[Bug middle-end/21478] New: Improve initialization of sparse local arrays
Large local arrays that are initialized to constant values, gcc uses a static
template and a call to
memcpy. If these arrays are all or mostly zeroes, if we clear the array using
memset and then initialize
the non-zero values inline, it is generally better in two ways:
a) it is faster
b) it requires less program memory overhead to store the array of initializers
Here is an example of source code that gcc could do better on:
void bar (char *);
void foo (void)
{
char bigarray[0x1000] = { 0 };
bar (bigarray[0]);
}
Which generates a 0x1000 byte constant array of zeroes. Instead, it would be
nice if gcc would just
memset the region to zeroes.
This construct is used extensively in the FAAD2 open source AAC encoder/decoder
library, resulting in
a 35%+ increase in size.
AFAICT, this applies to all targets, not just ARM.
--
Summary: Improve initialization of sparse local arrays
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jconner at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: powerpc-apple-darwin7.9.0
GCC target triplet: arm-none-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21478
[Bug middle-end/21478] Improve initialization of sparse local arrays
-- What|Removed |Added Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21478
[Bug middle-end/21478] Improve initialization of sparse local arrays
--- Additional Comments From jconner at apple dot com 2005-05-10 00:50 --- Proposed patch here: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00773.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21478
[Bug target/21128] New: Returning vector 32-bits or larger generates ICE
The following file:
typedef int __attribute__((vector_size (32))) v8i;
v8i g_v8i;
v8i return_v8i (void)
{
return g_v8i;
}
Compiled with the command-line:
gcc test.c -c
Produces this error message:
test.c: In function 'return_v8i':
test.c:5: internal compiler error: in hard_function_value, at explow.c:1541
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
This behavior shows up in the 4.0 branch and the current (4.1.0) mainline.
gcc 3.4.3 produces the following error message:
test.c:1: error: no vector mode with the size and type specified could be
found
My configuration is:
--target=arm-none-elf --program-prefix=arm-elf- --disable-nls
--enable-languages=c,c++ --
with-newlib --enable-multilib --disable-shared
This behavior shows up when trying to compile the test compat/vector-2.
--
Summary: Returning vector 32-bits or larger generates ICE
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jconner at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: powerpc-apple-darwin7.8.0
GCC target triplet: arm-none-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21128
[Bug target/21128] Returning vector 32-bits or larger generates ICE
-- What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21128
[Bug c/20972] New: Compiler-generated code produces an assembler warning
Test gcc.c-torture/compile/930210-1.c, when compiled with:
-O2 -c
produces the warning:
/var/tmp//ccSVOi5X.s: Assembler messages:
/var/tmp//ccSVOi5X.s:23: Warning: source register same as write-back base
Because of the following instruction generated in the assembly:
strbr2, [r2], #1
The assembler warning is produced because the instruction is unpredictable when
the source register
and the base destination register are the same and post-increment addressing is
used.
Note that while this test doesn't fail for the arm-none-elf target, a similar
test case does demonstrate
the same issue:
void f(void)
{
char c1, c2;
char *p1, *p2;
c1 = c2 = *p1++;
while (c1--)
*p2++ = *p1++;
}
This behavior is present in gcc-4.1.0-20050405, and gcc-4.0.0-20050410 (RC1).
Configuration options: --target=arm-unknown-elf --program-prefix=arm-elf-
--disable-nls --
enable-languages=c,c++ --with-newlib --enable-multilib --disable-shared
--
Summary: Compiler-generated code produces an assembler warning
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jconner at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: powerpc-apple-darwin7.8.0
GCC target triplet: arm-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20972
[Bug target/20972] Compiler-generated code produces an assembler warning
--- Additional Comments From jconner at apple dot com 2005-04-12 17:24 --- Subject: Re: Compiler-generated code produces an assembler warning I don't see this same behavior on 3.4.3. - Josh On Apr 12, 2005, at 10:08 AM, pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-12 17:08 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01291.html. Do you know if this is a regression from say 3.4.x? -- What|Removed |Added --- - CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2005-04-12 17:08:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20972 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20972
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From jconner at apple dot com 2005-04-11 21:10 --- Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail On Apr 10, 2005, at 8:50 PM, Alexandre Oliva wrote: On Apr 10, 2005, Mark Mitchell [EMAIL PROTECTED] wrote: Thanks for alerting me to this one; it does look relatively serious. I've added it to: http://gcc.gnu.org/wiki/Last-Minute%20Requests%20for%204.0.0 and will consider whether it merits a second release-candidate. FWIW, I've bootstrapped and regtested it on amd64-linux-gnu on 4.0 branch as well. The same patch applies cleanly. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} I'm now getting a ICE building the mainline (please ignore the 3.4.3 in the directory structure, it's a holdover from the build scripts I'm using) that appears to be related to this patch. Here's the output: ... /Volumes/Home/Users/josh/work/SameOld-mainline-elf/ToolsSrc/build-gcc -3.4.3-arm-elf-full/./gcc/xgcc -B/Volumes/Home/Users/josh/work/SameOld-mainline-elf/ToolsSrc/build- gcc-3.4.3-arm-elf-full/./gcc/ -c -DHAVE_CONFIG_H -O2 -g -O2 -I. -I/Volumes/Home/Users/josh/work/SameOld-mainline-elf/ToolsSrc/gcc/ libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes /Volumes/Home/Users/josh/work/SameOld-mainline-elf/ToolsSrc/gcc/ libiberty/cp-demangle.c -o cp-demangle.o In file included from /Volumes/Home/Users/josh/work/SameOld-mainline-elf/ToolsSrc/gcc/ libiberty/cp-demangle.c:99: /Volumes/Home/Users/josh/work/SameOld-mainline-elf/ToolsSrc/gcc/ libiberty/../include/libiberty.h:80: warning: function declaration isn't a prototype /Volumes/Home/Users/josh/work/SameOld-mainline-elf/ToolsSrc/gcc/ libiberty/cp-demangle.c: In function 'd_print_comp': /Volumes/Home/Users/josh/work/SameOld-mainline-elf/ToolsSrc/gcc/ libiberty/cp-demangle.c:3324: internal compiler error: in loop_givs_rescan, at loop.c:5501 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[1]: *** [cp-demangle.o] Error 1 make: *** [all-target-libiberty] Error 2 And my configuration: TOPLEVEL_CONFIGURE_ARGUMENTS=/Volumes/Home/Users/josh/work/SameOld- mainline-elf/ToolsSrc/gcc/configure --prefix=/Volumes/Home/Users/josh/work/SameOld-mainline-elf/ToolsSrc/ gcc/../../ToolChains/darwin-ppc/gcc-3.4.3/ --target=arm-unknown-elf --program-prefix=arm-elf- --disable-nls --enable-languages=c,c++ --with-newlib --enable-multilib --disable-shared FWIW, the mainline built successfully for me on 5 April. I'd be glad to enter a bug report, if it's appropriate -- I wasn't sure about proper behavior for a recently fixed bug. Otherwise, I'm also glad to provide any additional information that may help track down the issue. - Josh ~~ Josh Conner Apple Computer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
