ke the ".comm" directive. There only is the BSS storage class.
Do you know where I could find documentation for how to write out
something with BSS storage class? Is that something that GNU binutils
support, so that I can try it out?
Ciao!
Steven
by emitting
these things as top-level asms. That would make things with with LTO
also, and it is probably the easiest solution. It is a bit of a hack,
but IMHO that's not a problem for something as target-specific as
this.
If I can turn that idea into a patch, can you test it for me?
Ciao!
Steven
PS: nice to see you have a new employer ;-)
Ciao!
Steven
On Tue, Jun 5, 2012 at 8:55 PM, Iain Sandoe wrote:
> I would welcome a simple solution if one is available, although I don't quite
> see what you have in mind at present.
This is what I have in mind. Untested, but it shows the idea. What do
you think of this?
Ciao!
Steven
gcc/
On Wed, Jun 6, 2012 at 10:07 PM, Iain Sandoe wrote:
> Hi Steven,
> The attached patch survives normal and lto bootstrap on i686-darwin9 and
> x86_64-darwin10.
> No regressions for ObjC or Obj-C++.
> Otherwise, lightly tested, but appears to solve PR 48109 on the way.
>
> c
_section (SYMBOL_REF_DECL (addr), 0) is true, I would
expect that MEM_READONLY_P is set, and the decl_readonly_section check
is never true.
Is there a difference between "could be read-only"
(decl_readonly_section) and "is read-only" (MEM_READONLY_P)?
Thanks for any help you can give,
Ciao!
Steven
naming convention, the only difference is that it wraps the section
name in a segment label (always "__DWARF__") and adds some flags
(always "regular,debug"). I would have expected there to be a way to
change a section name in a target-specific way (something like a
targe
g: ‘coeff’ may be used uninitialized in
this function [-Wmaybe-uninitialized]
if (choose_mult_variant (mode, coeff, &algorithm, &variant, max_cost))
^
Could you have a look please?
Ciao!
Steven
lease?
>
> You just need [1].
>
> [1] http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00145.html
Silly me wonders why this warning doesn't cause a bootstrap failure...
Ciao!
Steven
help will be
> very appreciated.
>
> Does the gcc project provide access to the platforms mentioned above? I have
> an account at the gcc compile farm, but this does in particular not cover
> the proprietary platforms.
None of the above are available AFAIK.
Ciao!
Steven
Hello Joseph,
In revision 175064 you introduced a new subdirectory: gcc/common.
This directory is not documented in sourcebuild.texi. Can you please
add documentation for it?
Thanks,
Ciao!
Steven
d have to compute block local properties yourself. You can use
lcm.c:compute_available() though.
> 3. do propagation as usual by calling copyprop_hardreg_forward_1.
> 4. make cprop_hardreg do const propagation with some other trivial
> modifications.
You'll find these modifications will not be trivial.
Ciao!
Steven
Bin Cheng wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44025
You could foster-parent and fix the attached patch to address this issue.
(I'm not interested in pursuing this further myself.)
Ciao!
Steven
cse_uncprop.diff
Description: Binary data
On Wed, Jul 25, 2012 at 3:35 AM, Bin.Cheng wrote:
> On Wed, Jul 25, 2012 at 2:14 AM, Steven Bosscher
> wrote:
>> Bin Cheng wrote:
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44025
>>
>> You could foster-parent and fix the attached patch to address this
ic blocks
> in reverse post-order. Turns out the benefit is very small, because either
> the default order of iteration is nearly reverse post order, or the global
> propagation opportunities are along with loops.
Thanks for trying it. You're right, for loop-carried dependencies a
different iteration order wouldn't make a difference.
Ciao!
Steven
Hello,
There are ~1000 uses of gen_rtx_SET in gcc, excluding generated files.
The vast majority generate a SET with VOIDmode, but a few (less than
100) use a non-VOIDmode SET.
What is the meaning of the mode on a SET?
Ciao!
Steven
quot;int". Is loop_depth<0 used as a
special case? If so, then I think loop_depth(loop_p) should be changed
to return "int", otherwise bb->loop_depth should be made an "unsigned
int". What do you think about this?
Ciao!
Steven
tighten_loop_verifier.diff
Description: Binary data
On Sat, Aug 11, 2012 at 11:16 PM, Steven Bosscher wrote:
> Lots of test cases fail with the attached patch.
Lots still fail after correcting the verifier :-)
920723-1.c: In function 'f':
920723-1.c:14:1: error: bb 13 has loop depth 2, should be 1
f (int count, vector_t * pos, dou
hed bb->loop_depth saves two indirect references. But if it's
hard to maintain, I'd be happy to see it go away. Just so long as
bb->loop_father is correct (to be verified by a patch for the loop
verification code).
Ciao!
Steven
sted since than).
As per the development plan (http://gcc.gnu.org/develop.html) I'd like
to start the 48hr clock for patch reversion.
Ciao!
Steven
t 1 in insn 27: (0) r (1) rm
Choosing alt 1 in insn 31: (0) m (1) re
You do update the DF_LR sets elsewhere in LRA, so I was wondering if
it is intentional or not to leave the DF_LR sets unchanged after
elimination.
Ciao!
Steven
-- 8< --
EXECUTE_
/ml/gcc-patches/2012-08/msg00270.html
If it's a regression then perhaps the patch could be back-ported to
open release branches.
Ciao!
Steven
touched, you could just save and
restore them in the function ("callee saved" so to speak). But I don't
know how useful that would be.
Another, IMHO more interesting, thing to investigate would be
allocating global variables to registers. This is not part of Vlad's
original patch and I have no real ideas right now how to do that, but
it would be an interesting optimization for single-thread programs
(like GCC itself).
Ciao!
Steven
is enabled with
-Os, PRE is disabled.
* MR PRE was replaced with edge-based lazy code motion even before GCC 3.0
* loop code motion is now done on GIMPLE way before RTL PRE
* ... (probably half a dozen more issues) ...
If you file a PR, I'll update the documentation for the old gcse.c
passes (HOIST, PRE, CPROP).
Ciao!
Steven
n trying to hoist an expression). Could this be done in
> current DF infrastructure?
This should already be happening. But you should update the stuff you
get back from df_get_live_{in,out}, not DF_LR_{IN,OUT}.
> 2. I did not find any DF interface to calculate reference information
> for newly created insn, so how could I do this?
Should also already be happening on-the-fly.
Ciao!
Steven
e code is
quite good, but if you have any specific questions then there's always
this mailing list :-)
Ciao!
Steven
ing whatever transformation
it's attempting. Not enough information.
Ciao!
Steven
On Wed, Oct 24, 2012 at 6:11 PM, Christophe Lyon wrote:
> On 24 October 2012 00:42, Steven Bosscher wrote:
>> On Tue, Oct 23, 2012 at 10:29 PM, Christophe Lyon wrote:
>>> Well, both of these functions appear to check that the 2 blocks to
>>> merge belong to the same pa
n.
...
It's kinda nice to check target code as well when changing things... ;-)
Is the change at the bottom of this email correct?
Ciao!
Steven
Index: config/rs6000/rs6000.c
===
--- config/rs6000/rs6000.c (revision
om that code base
instead. The problem is that this bug only triggers with some profile
data, but you could attach gcda/gcno files to a PR.
Ciao!
Steven
On Fri, Oct 26, 2012 at 12:14 AM, Steven Bosscher wrote:
> On Thu, Oct 25, 2012 at 4:10 PM, Christophe Lyon wrote:
>> It looks like something is wrong with the CFG:
>>
>>|
>>19 (COLD)
>> / \
>>/ \
>> 20 (COLD) 21 (COLD)
&
be
shared: the source file that causes the ICE, the gcda+gcno files for
the profile, the compiler SVN revision number, and the compiler
configuration and options.
Ciao!
Steven
On Fri, Oct 26, 2012 at 2:16 PM, Christophe Lyon wrote:
> I also use some patches posted by Matthew Gretton-Dann, which are
> still under discussion: I will open a PR, and attach these patches
> too. Is it OK?
Yes, that'd be all that's needed to reproduce the bug.
Ciao!
Steven
On Fri, Nov 2, 2012 at 11:01 AM, Bin.Cheng wrote:
> Hi Steven,
> You mentioned the flag_gcse_las may be very useful for RISC machines in
> thread : http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00031.html
>
> I took some time to understand the code and think it should be workab
0-03/msg01103.html)
I suppose LRA counts, even if it doesn't get rid of reload completely just yet.
Bump the number! :-)
Ciao!
Steven
On Tue, Nov 6, 2012 at 1:17 AM, Ian Lance Taylor wrote:
> On Mon, Nov 5, 2012 at 3:45 PM, Steven Bosscher wrote:
>> On Wed, 24 Mar 2010 04:34:15 +, Dave Korn wrote:
>>>
>>> Say, why don't we reserve GCC 5.0 for the first version that gets rid of
>>&
harder to
track can be in GGC space with more flexible roots that can be set at
run-time (e.g. ggc_make_root (basic_block_il_dependent.x.head) and
ggc_discard_root(...) if CFG data structures live in pools but the RTL
insns stream lives in GC space).
Pie in the sky...?
Ciao!
Steven
s
that's something you could look into also, while at it?
Thanks for all the C++ and other compiler long-term structural improvements!!!
Ciao!
Steven
ys :-)
and how HP-PA can do something similar.
The comment in reorg.c looks out of place now, and the ability of
PA-RISC to nullify instructions isn't mentioned anywhere. AFAICT GCC
does not exploit this ability so I've added a comment for a suggested
improvement in pa.md
On Sun, Nov 25, 2012 at 4:44 PM, John David Anglin wrote:
> On 24-Nov-12, at 9:19 PM, Steven Bosscher wrote:
>
>> +;; This machine description is inspired by sparc.md and (to a lesser
>> +;; extend) mips.md.
>
>
> Change "extend" to "extent". D
On Sun, Dec 2, 2012 at 12:59 AM, John David Anglin wrote:
> On 1-Dec-12, at 6:45 PM, Steven Bosscher wrote:
>
>>
>> How about this?
>
>
> PA part looks good. Thanks.
Great, thanks! I've committed the PA part with a few typo fixes, and
the reorg.c part as obviou
Hello,
Someone broke bootstrap on powerpc64-linux between r194084 and
r194141. Anyone else seeing this?
Ciao!
Steven
../../../../../trunk/libstdc++-v3/src/c++98/locale-inst.cc:338:8:
error: '
On Tue, Dec 4, 2012 at 4:44 PM, Steven Bosscher wrote:
> Hello,
>
> Someone broke bootstrap on powerpc64-linux between r194084 and
> r194141. Anyone else seeing this?
>
> Ciao!
> Steven
Looks like someone used a broken editor replacing tabs with spaces:
2012-1
On Tue, Dec 4, 2012 at 4:47 PM, Steven Bosscher wrote:
> On Tue, Dec 4, 2012 at 4:44 PM, Steven Bosscher wrote:
>> Hello,
>>
>> Someone broke bootstrap on powerpc64-linux between r194084 and
>> r194141. Anyone else seeing this?
>>
>> Ciao!
>> Steve
On Tue, Dec 4, 2012 at 5:22 PM, Andreas Schwab wrote:
> Steven Bosscher writes:
>
>> Fixed with http://gcc.gnu.org/viewcvs?view=revision&revision=194152
>
> I think if you had changed to it would have a
> better chance to survive broken editors.
I only put back wha
measured/investigated what PCH
writer functions are actually used? Should we (as an intermediate step
towards streaming PCHs) explicitly GTY-mark types that should have PCH
writer functions, and not generate such functions for unmarked types?
Ciao!
Steven
GC_hierarchy.diff
Description: Binary data
On Tue, Dec 11, 2012 at 5:11 PM, Diego Novillo wrote:
> On Mon, Dec 10, 2012 at 1:25 PM, Steven Bosscher wrote:
>> This all made me wonder why we can't use the known hierarchy of the
>> intermediate representations. Ideally, there should be only two
>> classes of objec
via symtab_nodes
gimple call_stmt; // reachable via the CFG that contains the call
...
}
so, at least in theory, it shouldn't be necessary to do anything for a
cgraph_edge.
Unless I'm missing something...
Ciao!
Steven
PS: shouldn't "struct symtab_node" have GTY next/prev markers?
ed (always true)
* X86_ARCH_CMPXCHG/X86_ARCH_XADD/X86_ARCH_BSWAP can be removed.
* The only ix86 variant without lock-free atomic int support goes
away, which probably allows for a few more cleanups in some of the
libraries (?).
Not much, but something is more than nothing :-)
Ciao!
Steven
On Wed, Dec 12, 2012 at 8:39 PM, Robert Dewar wrote:
> On 12/12/2012 1:01 PM, Steven Bosscher wrote:
>>
>> Hello,
>>
>> Linux support for i386 has been removed. Should we do the same for GCC?
>> The "oldest" ix86 variant that'd be supported would
imary platform.
Ciao!
Steven
d. Dropping something as a target is not the same as
dropping it from the list of primary platforms.
See http://gcc.gnu.org/gcc-4.8/criteria.html
Ciao!
Steven
ware.
(see e.g. http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary -- actually, it
looks like libatomic currently doesn't support 386 at all)
But we digress...
Ciao!
Steven
t;frequently used" on FreeBSD so
> that's not in violation.
The "it's 386, nobody uses it" clause? I wouldn't mind if some other
freebsd tripled would stay on the list, e.g. i686-freebsd.
Stop being so emotional and look at the facts. Nobody is taking away
your favorite toys.
Ciao!
Steven
eebsd7.2.
That'd be in 2009...
But, again, we digress. I don't think anyone's arguing for dropping
BSDs from the primary/secondary targets lists. All I'm arguing for, is
to drop a 30 year old architecture that really nobody uses: 80386.
Ciao!
Steven
http://gcc.gnu.org/gcc-4.7
On Thu, Dec 13, 2012 at 2:40 PM, John Marino wrote:
> Everything I have said is a fact, please illustrate which statement I made
> seems emotional.
Joining in this discussion at all? I wish *bsd people were just as
responsive to bug reports...
Ciao!
Steven
Is it possible to identify the branch in the compiler version somehow?
I see the "REVISION" file mentioned in configure.ac and Makefile.in.
Should that file be used for this?
Ciao!
Steven
). They run within 24 hours after something
changes on the lra-branch, and post test results to gcc-testresults if
build+test was successful. I'll watch the testers and report build
failures manually here.
Ciao!
Steven
On Sat, Dec 22, 2012 at 5:15 PM, Steven Bosscher wrote:
> Vlad, I've set up auto-testers for the lra-branch on gcc110
> (powerpc64) and gcc66 (ia64). They run within 24 hours after something
> changes on the lra-branch, and post test results to gcc-testresults if
> build+test was
On Tue, Mar 27, 2012 at 10:59 AM, Richard Guenther wrote:
> On Tue, Mar 27, 2012 at 10:32 AM, Steven Bosscher wrote:
>> On Tue, Mar 27, 2012 at 9:17 AM, Richard Guenther wrote:
>>> It would be nice to finally move
>>> the call to cgraph_finalize_compilation_unit to the
+-+ +-+
These "false" control dependences are in my way for a couple of
tree-ssa-sink improvements, and probably are harmful for other
control-dependence based transformations as well. It also makes the
control dependence graph larger and more complex than necessary.
Th
= PHI <0(5), r_4(3)>
# VUSE <.MEM_2(D)>
return r_1;
}
Why are those VUSEs there?
Ciao!
Steven
*" sections, and the ".text*" size is subtracted
to get the debug info sizes.
Unless someone can shoot holes in this test approach, the results
suggest that DWARF debug size is *smaller* than stabs, at least for
mipsisa64.
Ciao!
Steven
On Tue, Jan 15, 2013 at 6:53 PM, Jan Kratochvil wrote:
> On Tue, 15 Jan 2013 11:09:46 +0100, Steven Bosscher wrote:
>> Unless someone can shoot holes in this test approach,
>
> While the sum of *.o files sizes may make sense in some cases I would find
> more useful to measure it
))
67125296:13.8% 33562640:38.4% 0: 0.0% 64: 0.0%
4
Is this a known issue?
Ciao!
Steven
On Mon, Jan 28, 2013 at 4:47 PM, Diego Novillo wrote:
> On Sun, Jan 27, 2013 at 7:09 AM, Steven Bosscher wrote:
>
>> Is this a known issue?
>
> No, thanks for the report. I'll try to see what's going on (though
> you may need to ping me in a few days).
http://www.
(and worth the effort) to implement
something that keeps clobbers for registers that are live above the
clobber after removing the clobber?
Ciao!
Steven
is insn and never used. */
REG_NOTE (UNUSED)
After all, a CLOBBER is not a register set, so I think a patch like
the one below is necessary.
Thoughts?
Ciao!
Steven
* df-problems.c (df_note_bb_compute): Do not set REG_UNUSED notes
on CLOBBERs.
Index: df
cision, so I'd go ahead with your patch.
That's what I believe, too. Still, combine appears to add REG_UNUSED
notes for clobbers intentionally. Do you know why it does that?
Ciao!
Steven
/* Like recog, but we receive the address of a pointer to a new pattern.
...
Modifications incl
me.c is a different "fix" for the same PR, and it
looks to me like it's not the right fix...
On top of the REG_EQ* work, I see more REG_* notes work for GCC 4.9 :-)
Ciao!
Steven
really. There seems always to be something that prevents them from
> being deleted, and I have no time to spend on GCC at work right now. I
> believe Steven Bosscher has more detail on that than I do.
We had this discussion last year. The only reason to still have
libcalls was for TLS address
the no-conflict blocks were not as important anymore since
your subreg lowering work, and maybe even since we started doing
"real" liveness analysis (i.e. flow.c in ~1997 ;-))
What do you think, is this a blocker issue?
Gr.
Steven
written before
> DF, and I haven't found the time to upgrade it to the DF framework.
OK. Then I'm not going to work on removing libcall notes. If it's
still necessary to have them, well, you know, it's kinda pointless ;-)
Gr.
Steven
that GCC still needs libcalls for, and make your new bug
report block PR34513. Of course, it'd help if you then go on and
remove that dependency on libcall notes ;-)
Gr.
Steven
s in gcse.c. When faced with a
PHI node, those optimizers would punt and lose.
Gr.
Steven
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?
Gr.
Steven
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
&
all of these were flying with certified software.
Gr.
Steven
dd PHI
functions and let the "normal" UD-chains point to the PHI function
arguments?
What about keeping things up-to-date after applying some
transformations? It is already hard to keep UD/DU chains up-to-date
now (I don't think any pass successfully does so right now). This
should be a lot easier if you fully factorize your UD chains, right?
Gr.
Steven
ions, I would *not* keep them on
the side. If you have something special going on, my motto is: "Make
it explicit".
Gr.
Steven
true, but update_ssa used to walk a huge
part of the dominator tree even for seemingly trivial updates. We
should not want that on RTL. I don't think we should allow
transformations on RTL that are too hard to manually update the FUD
chains somehow.
Gr.
Steven
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
into SSA
(pseudos are not shared); etc.
But Kenny has already said he wants to have a full replacement for
reaching defs, so the point's become moot :-)
Gr.
Steven
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
for the
whole function, like GCC did before Peter's work. This could be a
huge memory and speed regression if it isn't addressed.
Another note: IRA uses VARRAYs, and I was under the impression we are
trying to move away from those. Vlad, please use VECs instead.
Gr.
Steven
ranch
islands for the __tls_get_addr calls?).
Thanks,
Gr.
Steven
(nil)))
This insn is generated by gen_move_insn in gcse.c:replace_store_insn().
Maybe that should be emit_move_insn()?
Gr.
Steven
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
27;re only talking in terms of
solutions. But what *exactly* are you trying to do? You ave to
modify the SET_SRC of some SETs. What do these SET_SRCs look like?
This is important, because if you are only looking at registers, maybe
you can easily access them through DF_INSN_DEFS.
Gr.
Steven
568.html and let it rest ;-)
Gr.
Steven
Hi,
Hi,
Everyone else is creating branches today, so let me join the club and
announce a new branch: rtl-fud-branch. The purpose of the branch is to
implement factored use-def chains for RTL. The goal is to have this
ready for GCC 4.4.
Gr.
Steven
Index: svn.html
.
Things would be so much better for me if we'd only test a subset of
libjava by default... *sigh*
Gr.
Steven
pple is clearly not keeping its
promise to maintain it, and AFAIK no-one else uses this language.
Gr.
Steven
s.
>
> ...
> ;; Succ edge 10 [91.5%] (fallthru)
>
> ;; Succ edge 9 [8.5%]
>
> ;; Start of basic block ( 8) -> 9
> ...
Yes, this is valid if you are in cfglayout mode.
Gr.
Steven
I promise I will analyze why we don't fold away the
ADDs, and why the scheduler doesn't glob the loads (may be due to bad
alias analysis, but maybe something else is not working properly).
Gr.
Steven
lobber the whole compiler,
> rebuild the compiler by "CFLAGS='-DHAVE_doloop_end'", it still will
> complain error, can't find the gen_doloop_end.
>
> so the first question is: does SMS is support on X86?
No. the x86 backend has no doloop insn pattern. To see what that
means, see loop-doloop.c, and look for doloop in
http://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html.
Gr.
Steven
y compute a dependence
distance on RTL, so for memory the DDG is just very conservative.
You're not telling anything new, you know ;-) You probably want to
read http://gcc.gnu.org/wiki/SwingModuloScheduling too,
Gr.
Steven
PR again, you're not explaining the problem
there either, only the symptom. Surely, you didn't wonder off into
libgfortran land if you didn't have a piece of real world code that
has issues with the current libgfortran chmod? ;-)
Gr.
Steven
meone else who can commit to working on it as a high priority after
> the main tuples checkin?
If this pass is effectively unmaintained, why not just remove it?
Unmaintained passes that are not enabled at any optimization level are
usually broken anyway.
Gr.
Steven
901 - 1000 of 1056 matches
Mail list logo
