at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32602
--- 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
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
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
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
--- 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
--- 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
--- 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
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
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
--- 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
at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24663
: jconner at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24664
--- 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
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
--- 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
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
--- 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
--- 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
--- 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
--- 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
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
--
What|Removed |Added
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23241
--- 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
: 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
: 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
--
What|Removed |Added
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21648
--- 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
: 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
--
What|Removed |Added
Keywords||missed-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21478
--- 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
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
--
What|Removed |Added
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21128
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
--- 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
--- 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
43 matches
Mail list logo
