On 28 Feb 2008 12:41:30 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> libcalls are still used for no-conflict blocks. This may be what you
> mean by the scheduling thing. No-conflict blocks are emitted by
> emit_no_conflict_block and checked in local-alloc.
I thought the no-conflict bl
On 28 Feb 2008 13:52:56 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> I think it's probably a blocker issue on 32-bit x86 until we complete
> the lower subreg work to track subreg lifetimes to detect no-conflict
> sections manually. I have an implementation of that written before
> DF,
Hello,
Every time someone brings up the idea to remove libcall notes, people
have to think really hard why GCC still has them. It seemed like a
good idea to record and collect these issues in a meta-bug. Thus, see
PR35413. Please open a new bug report (enhancement request, probably)
for things t
On Fri, Feb 29, 2008 at 11:51 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> If we are not going to use a rewriting SSA form, I believe that the
> original problems we had with RTL-SSA can be avoided.
The nice thing about birth points would be that most RTL optimizers
can look through NOPs (amaz
On Sat, Mar 1, 2008 at 11:03 AM, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> > The two complications are:
> > 1) libcalls
>
> I am probably dense here, but why we can't just ignore existence of
> libcalls for dataflow framework?
Not libcalls, but libcall *notes*.
> This exist so we can effectiv
On Sat, Mar 1, 2008 at 3:01 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On 2/29/08 10:01 PM, Kenneth Zadeck wrote:
>
> > it is more productive to spend the cycles getting rid of the libcalls
> > rather than figuring out the edge cases. as steven implied, we have
> > been on the verge of get
> There has been at least one incident of a software bug in certified
> code, but it is very rare, and the record is impressive (no life
> has been lost because of a software bug in the history of commercial
> aviation).
I agree with all you've said so far, but this statement above is a bit
too op
On Sat, Mar 1, 2008 at 2:46 PM, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>
> > By the way, I still don't understand how birth points would work. Can
> > someone give an example of what the insn stream would look like with
> > birth points, and what the DU/UD chains would look like?
>
> With a
On Sat, Mar 1, 2008 at 11:13 AM, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> > Diego,
> >
> > I am leaning to just adding noop moves at the birthpoints (dominance
> > frontiers) as real noop move insns in the streams in the passes that use
> > ud or du chains. The back end is tolerant of noop mo
On Tue, Mar 4, 2008 at 7:58 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> Both PHIs and birthpoints are merely factoring devices that let you cut
> down the number of UD links. They don't need to be part of the IL, much
> like none of the DF objects are part of the RTL IL.
Maybe they don't ne
On Tue, Mar 4, 2008 at 8:47 PM, Richard Sandiford
<[EMAIL PROTECTED]> wrote:
> "Steven Bosscher" <[EMAIL PROTECTED]> writes:
> Going back to something discussed upthread: would you expect to use this
> for hard regs as well as pseudos? No-op moves aren't n
On Tue, Mar 4, 2008 at 9:46 PM, Richard Sandiford
<[EMAIL PROTECTED]> wrote:
> I don't see why hard registers are special as far as FUD chains go.
> We have DU chains for hard regs, so why not FUDs too?
We have them, but does anyone use them? Does anyone actually even
compute them? (Apparently
On Sat, Mar 1, 2008 at 12:31 AM, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> Please open a new bug report (enhancement request, probably)
> for things that GCC still needs libcalls for, and make your new bug
> report block PR34513. Of course, it'd help if you then go o
On Tue, Apr 29, 2008 at 6:22 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Vladimir, if you feel that Peter's code cannot be used directly in IRA,
> would you please explain why not?
I think he already has explained, see
http://gcc.gnu.org/ml/gcc/2008-04/msg00730.html
Having looked at IRA a bit
Hi,
Can anyone give me a pointer to how TLS is supposed to work on powerpc-darwin?
I can't find any references, and I am trying to figure out whether I
need to do something special for it when I change the rs6000 backend
TLS support (e.g. should I expect any target to maybe require branch
islands
xf. http://gcc.gnu.org/ml/gcc/2008-05/msg00274.html
> Why is store_motion doing this?
>
> STORE_MOTION delete insn in BB 2:
> (insn 8 7 27 2 dj.c:10 (parallel [
> (set (mem/s/j:HI (reg/v/f:HI 26 [ s ]) [0
> .buf+0 S2 A8])
> (ashift:HI (re
On Wed, May 21, 2008 at 11:41 PM, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> Maybe that should be emit_move_insn()?
OK, so that is not it.
The problem is that can_assign_to_reg_p() returns true when x is
(ashift:HI (reg/v:HI 27 [ n ]) (subreg:QI (reg/v:HI 27 [ n ]) 0)).
num_clobbers
On Thu, May 22, 2008 at 12:06 AM, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> On Wed, May 21, 2008 at 11:41 PM, Steven Bosscher <[EMAIL PROTECTED]> wrote:
>> Maybe that should be emit_move_insn()?
>
> OK, so that is not it.
>
> The problem is that can_assign_
Hi,
This is just a heads-up for this patent Sun Microsystems is claiming
on the construction of "Factored assert chains", see
http://www.patentstorm.us/patents/7272829/description.html
I wonder if GCC's VRP ASSERT_EXPRs would be considered prior art.
Gr.
Steven
On Tue, Jun 10, 2008 at 8:22 PM, Joern Rennecke <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 10, 2008 at 01:44:08PM -0400, Kaveh R. GHAZI wrote:
>> I don't understand the point about the asm.
>
> I need to modify the SET_SRC of the individual SETs presented by
> note_stores. The caller of note_stores
On Tue, Jun 17, 2008 at 3:58 PM, David Kastrup <[EMAIL PROTECTED]> wrote:
> Probably better would be to just disable the crossjumping optimization
> for calls of abort. Maybe this would warrant a new attribute.
Read the long thread starting at
http://gcc.gnu.org/ml/gcc/2005-03/msg00568.html and l
be marked with the tag
[thread-annotations] in the subject line.
+ rtl-fud-branch
+ This branch is for the development of factored use-def chains
+ as an SSA form for RTL. Patches should be marked with the tag
+ [rtl-fud] in the subject line. The branch is maintained
+ by Steven Bosscher
On Fri, Jun 20, 2008 at 11:16 PM, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> On Fri, 20 Jun 2008, Diego Novillo wrote:
>
>> On Fri, Jun 20, 2008 at 16:56, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
>>
>> > That aside, our current policy already allows e.g. not testing java if
>> > your change is to
On Sat, Jun 21, 2008 at 12:41 AM, Kaveh R. Ghazi <[EMAIL PROTECTED]> wrote:
> Fundamentally, our philosophy has been to catch errors *before* they get
> into the repository. Sure one day of breaking the trunk isn't so bad, but
> when it breaks it affects hundreds of developers and it adds up.
But
On Fri, Jun 27, 2008 at 2:20 PM, Bingfeng Mei <[EMAIL PROTECTED]> wrote:
> Hello,
> I try to locate a problem in GCSE pass and found some suspicious RTL
> code as follows. Is it legitimate to have a "fallthru" succ edge but
> next basic block is a different one? Thanks.
>
> ...
> ;; Succ edge 10
On Wed, Jul 2, 2008 at 1:13 PM, Bingfeng Mei <[EMAIL PROTECTED]> wrote:
> Hello,
> I am looking at GCC's loop unrolling and find it quite inefficient
> compared with manually unrolled loop even for very simple loop. The
> followings are a simple loop and its manually unrolled version. I didn't
> ap
On Fri, Jul 4, 2008 at 12:05 AM, Tianwei <[EMAIL PROTECTED]> wrote:
> Hi, all,
>My current project wants to reuse DDG's infrastructure to get some
> loop carried dependency information, I debug these code for a while,
> but have some questions, Hope you can
> give me some suggestions.
>
> 1. my
On Fri, Jul 4, 2008 at 1:25 AM, Tianwei <[EMAIL PROTECTED]> wrote:
> it won't query the aliaser for more precise information, maybe the
> code is a little older.
Not at all, the DDG file is for the SMS pass which is relatively new.
One of the problems is that you can't really compute a dependence
On Wed, Jul 9, 2008 at 11:48 PM, H.J. Lu <[EMAIL PROTECTED]> wrote:
>> In that chmod() is not defined by the Fortran Standard,
>> how can you infer that libgfortran's implementation is
>> incorrect?
>>
>
> Please read a decent UNIX system book or look how
> system () is implemented in glibc.
Well,
On Fri, Jul 25, 2008 at 6:19 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Diego Novillo wrote:
>
>>> Why not fix that before merging, then?
>>
>> Because it is not a pass that is run by default, it is not receiving
>> active maintenance and the cost/benefit of doing it pre-merge is lower
>> than
On Tue, Jul 29, 2008 at 11:26 AM, Richard Guenther
<[EMAIL PROTECTED]> wrote:
>> g++ (v. 4.2.3) without any options converts memcpy with unknown size to rep
>> movsb
>
> Make sure to use -D__NO_STRING_INLINES to not get glibcs inline
> implementation.
Why is this not the default?
Gr.
Steven
On Mon, Aug 11, 2008 at 3:55 PM, Andrey Belevantsev <[EMAIL PROTECTED]> wrote:
> 1. Make the required fixes inside the cfglayout hooks so that both the new
> behavior and the old behavior is supported and the user can choose one of
> them. As we still need to see the created jumps, we need to make
On Mon, Aug 11, 2008 at 10:02 PM, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am probably missing something:
>
>> The basic idea is enabling cfglayout mode and then ensuring that insn
>> stream and control flow are in sync with each other at all times. This
>> is required because e.g. on I
On Thu, Aug 14, 2008 at 6:52 PM, Tom Tromey <[EMAIL PROTECTED]> wrote:
> I'd like to see carets on by default as part of a major release -- say
> GCC 5.0. (First mention!!)
Whoa, you wish :-)
Honors go to Marc Espie here:
http://gcc.gnu.org/ml/gcc/2000-12/msg00636.html
But there've been several
On Thu, Sep 11, 2008 at 10:38 AM, Thomas A.M. Bernard <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I inserted some extra instructions in the Alpha back-end (MD files). They
> are properly emitted when the flag -O0 is enabled. Since they have no side
> effects and no dependencies on other instructions, they
On Fri, Sep 19, 2008 at 6:36 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> @@ -7674,12 +7713,8 @@ build_common_tree_nodes (bool signed_cha
> unsigned_char_type_node = make_unsigned_type (CHAR_TYPE_SIZE);
> TYPE_STRING_FLAG (unsigned_char_type_node) = 1;
>
> - /* Define `char', which is like e
On Sun, Sep 21, 2008 at 2:28 PM, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> Index: tree.c
> ===
> --- tree.c (revision 140524)
> +++ tree.c (working copy)
> @@ -7364,8 +7364,8 @@
> bu
On Wed, Sep 24, 2008 at 4:06 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Apple's dislike of GPLv3 is a problem for gcc, yes.
Well, excuse me for being a-political, but I don't see this problem.
The relationship between GCC and Apple has never been really good
AFAIK, but that hasn't hampered
On 5/7/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
Richard Guenther wrote:
> On 5/7/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
>
>>
>> Compilation time SPECINT2000 (user time sec):
>> **Mainline Branch Change
>>
>> x86_64139.39 148.48 +6.
On 5/8/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>>> Because it's the semantics of libcall sequences. My take is that the
>>> lower subreg pass breaks it in this case.
>
>I could "fix" it at -O2 with -fno-split-wide-types or at -O1 with
> -fno-move-loop-invariants or -fno-split-wide-type
On 5/8/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> But without libcall notes, we just see a call_insn and a set to a hard
> register, and we have no way to tell that the call_insn is dead and
> can safely be removed.
Even if CONST_OR_PURE_CALL_P is set to 1??? :-(
I don't know, but in any
On 5/9/07, Mike Stump <[EMAIL PROTECTED]> wrote:
In ipa-type-escape.c we have:
/* Return either TYPE if this is first time TYPE has been seen an
compatible TYPE that has already been processed. */
I'd fix it, if I knew I knew what it meant. either, an and that are
the things that are c
On 5/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
PR 31797: An infinite loop in the compiler while building RTEMS.
Daniel, I see you've been commenting on this; are you working on the
fix? If so, do you have an ETA?
Why are you waiting for this one? RTEMS is not a primary or secondary
platf
On 5/18/07, Bernardo Innocenti <[EMAIL PROTECTED]> wrote:
Come on, 4.3 doesn't look in such a bad shape!
It will soon, when the stage1 projects are finally merged into the trunk.
BTW, the tentative timeline says that 4.3 stage 1 will end
4 months *ago*:
http://gcc.gnu.org/develop.html#timel
On 5/21/07, Tehila Meyzels <[EMAIL PROTECTED]> wrote:
Hi,
I'd like to get an explanation why ifcvt.c checks whether 1 of the 2
successors of the IF-header block has a stmt that exits from the loop?
Why does it prevent the if-conversion?
I'm referring to the following code:
/* Nor exit the loop
On 5/21/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
On 5/21/07, Mike Stump <[EMAIL PROTECTED]> wrote:
> Please resubmit against 4.3 (the top of the svn tree)... This is the
> canonical place where developers should be doing development. Thanks.
Except loop.c has been removed already which has
Hello,
Earlier this year, I had a chat with Richard Earnshaw about code size
optimizations in GCC. I'm of the opinion that GCC should be able to
do better, if a small number of obvious shortcomings would be fixed.
There are many passes that matter for code size, which are currently
rather impaire
On 10/20/07, Chris Lattner <[EMAIL PROTECTED]> wrote:
>
> On Oct 20, 2007, at 4:48 AM, Steven Bosscher wrote:
>
> > I hope the list is useful for someone who wishes to improve GCC's
> > optimizations for code size.
>
> Is there a meta bug for code size op
On 11/1/07, Janis Johnson <[EMAIL PROTECTED]> wrote:
> Several options reported by --help=optimize are not documented in the
> GCC Manual (via invoke.texi) but are still reported with
> --help=optimize,^undocumented. Here are the options along with the
> people who checked in the entries to common
Hello,
While browsing through the mailing list archives a bit, I noticed
Alex's project to improve GCC's debug information. This seems like a
really interesting and worthwhile project. Alex, maybe you could add a
Wiki page about this project, in the style of
http://gcc.gnu.org/wiki/SampleProjectT
xf. http://gcc.gnu.org/ml/gcc/2007-11/msg00293.html
Mark Mitchell wrote:
> The reason I want to make that assumption is that the part of this where
> the representation is in question is once we reach RTL, right?
The representation in GIMPLE should also be discussed IMVHO. For
GIMPLE Alex has inve
Hello,
The amount of duplicate work done on RTL is sometimes really amazing,
especially since the merge of the dataflow branch. Some of the people
who have worked on the dataflow branch had hoped that other developers
would help with the follow-up actions to actually *use* all the
information tha
On Nov 18, 2007 7:28 AM, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> On Fri, 16 Nov 2007, Steven Bosscher wrote:
>
> > Question is, whether this kind of rather large changes is acceptable
> > for stage 3 or not. Me, I call it a "regression fix" if it reduces
>
On Nov 18, 2007 8:32 PM, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> On Sun, 18 Nov 2007, Steven Bosscher wrote:
>
> > 2. But *I will not work on it* now (or ask help from others) if it is *a
> > priori* not acceptable for stage 3.
>
> As I parse your sentence, you w
On Nov 18, 2007 10:29 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> I think the answer is that the patch is not a priori unacceptable.
>
> But, given that we're talking about a relatively large change, I think
> the bar should be set higher than for a change to just a few lines of
> code. In part
On Nov 23, 2007 9:45 PM, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> So, yes, debug stmts and insns are notes in the sense that they don't
> output code. Like USE insns, labels, empty asm insns and other
> UNSPECs. But wait, those are insns, not notes. And they do generate
> code, just not in t
On Nov 24, 2007 5:54 AM, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> > Apparently, you can't treat DEBUG_INSN just like any other normal
> > insn.
>
> Obviously not. They're weaker uses than anything else. We haven't
> had any such thing in the compiler before.
So we get a "third way". GCC has
Hello,
Back when God hadn't invented the dinosaurs yet (7 years ago) Joseph
opened a bug report requesting the creation of a gcc-cvs-patches
mailing list. The bug report can be found here:
http://gcc.gnu.org/PR1634.
Then, nothing happened for many years, a few comments aside.
Joseph wants to ke
Hello,
This is a complaint about how the bug database is being managed. It
is getting harder and harder to find bug reports to work on, because
too many old bug reports are being kept open even though there is no
sign of intent to ever resolve the report.
For example, PR18346 is a bug report in
On Dec 19, 2007 4:32 PM, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 19, 2007 at 01:59:51AM +0100, Steven Bosscher wrote:
> > The current list of "All regressions" should be a list of bugs that
> > people are actively trying to resolve, prefe
On Dec 20, 2007 9:00 AM, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Nov 5, 2007, "Steven Bosscher" <[EMAIL PROTECTED]> wrote:
>
> > Alex, maybe you could add a Wiki page about this project
>
> Done, at last! :-)
>
> http://gcc.gnu.org/wiki/Va
901 - 961 of 961 matches
Mail list logo
