On Tue, Sep 01, 2015 at 10:03:27PM -0700, Andy Lutomirski wrote:
> On Tue, Sep 1, 2015 at 9:55 PM, Rich Felker wrote:
> > On Tue, Sep 01, 2015 at 09:32:22PM -0700, Andy Lutomirski wrote:
> >> On Tue, Sep 1, 2015 at 9:18 PM, Rich Felker wrote:
> >> > On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy
On Tue, Sep 1, 2015 at 9:55 PM, Rich Felker wrote:
> On Tue, Sep 01, 2015 at 09:32:22PM -0700, Andy Lutomirski wrote:
>> On Tue, Sep 1, 2015 at 9:18 PM, Rich Felker wrote:
>> > On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy Lutomirski wrote:
>> >> On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker wrot
On Tue, Sep 01, 2015 at 09:32:22PM -0700, Andy Lutomirski wrote:
> On Tue, Sep 1, 2015 at 9:18 PM, Rich Felker wrote:
> > On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy Lutomirski wrote:
> >> On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker wrote:
> >> > On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy
On Tue, Sep 1, 2015 at 9:18 PM, Rich Felker wrote:
> On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy Lutomirski wrote:
>> On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker wrote:
>> > On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote:
>> >> Hi all-
>> >>
>> >> Linux has a handful of weird
On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy Lutomirski wrote:
> On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker wrote:
> > On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote:
> >> Hi all-
> >>
> >> Linux has a handful of weird features that are only supported for
> >> backwards compati
On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker wrote:
> On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote:
>> Hi all-
>>
>> Linux has a handful of weird features that are only supported for
>> backwards compatibility. The big one is the x86_64 vsyscall page, but
>> uselib probably belo
On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote:
> Hi all-
>
> Linux has a handful of weird features that are only supported for
> backwards compatibility. The big one is the x86_64 vsyscall page, but
> uselib probably belongs on the list, too, and we might end up with
> more at s
On Sep 1, 2015 6:12 PM, "Ian Lance Taylor" wrote:
>
> On Tue, Sep 1, 2015 at 5:51 PM, Andy Lutomirski wrote:
> >
> > Linux has a handful of weird features that are only supported for
> > backwards compatibility. The big one is the x86_64 vsyscall page, but
> > uselib probably belongs on the list
On Sep 1, 2015 6:53 PM, "Brian Gerst" wrote:
>
> On Tue, Sep 1, 2015 at 8:51 PM, Andy Lutomirski wrote:
> > Hi all-
> >
> > Linux has a handful of weird features that are only supported for
> > backwards compatibility. The big one is the x86_64 vsyscall page, but
> > uselib probably belongs on t
On Tue, Sep 1, 2015 at 8:51 PM, Andy Lutomirski wrote:
> Hi all-
>
> Linux has a handful of weird features that are only supported for
> backwards compatibility. The big one is the x86_64 vsyscall page, but
> uselib probably belongs on the list, too, and we might end up with
> more at some point.
On Tue, Sep 1, 2015 at 6:20 PM, DJ Delorie wrote:
>
>> It did match the first alternative (alternative 0), but it matched the
>> constraints Y/Y/m.
>
> It shouldn't match Y as those are for near addresses (unless it's only
> matching MEM==MEM), and the ones in the insn are far, but ...
Reload cho
> It did match the first alternative (alternative 0), but it matched the
> constraints Y/Y/m.
It shouldn't match Y as those are for near addresses (unless it's only
matching MEM==MEM), and the ones in the insn are far, but ...
> Reload doesn't have any concept of two different kinds of memory
>
On Tue, Sep 1, 2015 at 5:51 PM, Andy Lutomirski wrote:
>
> Linux has a handful of weird features that are only supported for
> backwards compatibility. The big one is the x86_64 vsyscall page, but
> uselib probably belongs on the list, too, and we might end up with
> more at some point.
>
> I'd l
David Malcolm :
> > Still, if anyone else is brave enough to write a script that will munch
> > through gcc-patches producing committer/date/subject-line triples, I'll
> > give it a try.
>
> I don't think committer/date/subject-line triples are adequate: the
> dates are unlikely to match up, for o
Hi all-
Linux has a handful of weird features that are only supported for
backwards compatibility. The big one is the x86_64 vsyscall page, but
uselib probably belongs on the list, too, and we might end up with
more at some point.
I'd like to add a way that new programs can turn these features o
On Tue, 2015-09-01 at 11:30 -0400, Eric S. Raymond wrote:
> Joseph Myers :
> > With 227369 revisions I don't think adding git-style summary lines is
> > really practical without some very reliable automation to match commits to
> > corresponding gcc-patches messages (whose Subject: headers would
On 09/01/2015 12:44 AM, DJ Delorie wrote:
> I expected gcc to see that the operation doesn't meet the constraints,
> and move operands into registers to make it work (alternative 1,
> "v/v/v").
It did match the first alternative (alternative 0), but it matched the
constraints Y/Y/m. Operands 1 an
On 09/01/2015 01:44 AM, DJ Delorie wrote:
Given this test case for rl78-elf:
extern __far int a, b;
void ffr (int x)
{
a = b + x;
}
I'm trying to use this patch:
Index: gcc/config/rl78/rl78-virt.md
===
--- gcc/config/rl78/rl78-
Snapshot gcc-5-20150901 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/5-20150901/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5
Steve Ellcey writes:
> On Tue, 2015-09-01 at 10:13 +0200, Georg-Johann Lay wrote:
>
> >
> > I'd have a look at what BEs are using non-default target_gtfiles.
> >
> > Johann
>
> There are a few BEs that add a .c file to target_gtfiles, but no
> platforms that add a .h file to target_gtfiles. I d
On Tue, 1 Sep 2015, Mikhail Maltsev wrote:
> Actually, I did not propose to alter the repository history. I just
> meant to say that if .c -> .cc renaming is still planned, it could be
> done right after conversion, as a normal commit, or, perhaps series of
> commits on trunk and active develop
On 09/01/2015 08:11 PM, Joseph Myers wrote:
> On Tue, 1 Sep 2015, Richard Earnshaw wrote:
>
>> Renaming the files during the conversion is clearly *not* the right
>> thing to do: it would break all builds of old code.
>
> Indeed. Ideally the tree objects in the git conversion should have
> exac
All:
The Live ranges info on tree SSA representation is important step towards the
SSA based code motion optimizations.
As the code motion optimization based on the SSA representation effects the
register pressure and reasons for performance
Bottleneck.
I am proposing the Live range Analysis ba
On Tue, 1 Sep 2015, Eric S. Raymond wrote:
> Joseph Myers :
> > Indeed. Ideally the tree objects in the git conversion should have
> > exactly the same contents as SVN commits, and so be shared with the
> > git-svn history to reduce the eventual repository size (except where there
> > are defe
All:
The Data Dependency graph augmented with control dependence can be common out
based on the dominator info.
The instruction I1 dominates all the uses say instruction I2 and I3. Then I2
and I3 depends on I1. Thus the Graph can be
Formed from the dominator tree of all the instructions and the
All;
The Global code motion are the important optimization that have an impact on
register spills and Fetch. Thus
The Global code motion takes into account the increase or decrease of register
pressure.
Strength Reductions is an important optimization that has an impact on register
pressure. T
Joseph Myers :
> Indeed. Ideally the tree objects in the git conversion should have
> exactly the same contents as SVN commits, and so be shared with the
> git-svn history to reduce the eventual repository size (except where there
> are defects in the git-svn history, or the git conversion fixe
On Tue, 1 Sep 2015, Richard Earnshaw wrote:
> Renaming the files during the conversion is clearly *not* the right
> thing to do: it would break all builds of old code.
Indeed. Ideally the tree objects in the git conversion should have
exactly the same contents as SVN commits, and so be shared w
On Tue, 2015-09-01 at 10:13 +0200, Georg-Johann Lay wrote:
>
> I'd have a look at what BEs are using non-default target_gtfiles.
>
> Johann
There are a few BEs that add a .c file to target_gtfiles, but no
platforms that add a .h file to target_gtfiles. I do see a number
of platforms that defin
On 09/01/2015 11:59 AM, Eric S. Raymond wrote:
Jason Merrill :
Here's an improved version:
You wrote:
# git scommit - list most recent commit that matches
.
# Must also specify a branch to search or --all.
Where must the branch argument appear with respect to the other arguments?
After
On Tue, 2015-09-01 at 08:11 +0100, Richard Sandiford wrote:
> config.gcc would need to add mips-private.h to target_gtfiles.
OK, that was what I missed.
> I'm not sure splitting the file is a good idea though. At the moment
> the definitions of all target hooks must be visible to a single TU.
>
"Eric S. Raymond" writes:
> There is no way to maintain those links for git, so yes, you want to
> keep a read-only Subversion instance around.
The mapping can also be put in some git notes tree for use by bugzilla.
That would only need to be set up once.
Andreas.
--
Andreas Schwab, SUSE Labs
Jason Merrill :
> Here's an improved version:
You wrote:
# git scommit - list most recent commit that matches
.
# Must also specify a branch to search or --all.
Where must the branch argument appear with respect to the other arguments?
Am I correct that this should be applied by creating or
David Malcolm :
> > What kind of mechanical transformation or hand-editing would add value for
> >you?
>
> Will the resulting git commits have some kind of metadata identifying
> the corresponding SVN revision?
That's what the --legacy option does. I think Jason plans to use it.
I've noted prev
Joseph Myers :
> With 227369 revisions I don't think adding git-style summary lines is
> really practical without some very reliable automation to match commits to
> corresponding gcc-patches messages (whose Subject: headers would be the
> natural choice for such summary lines)
In this case
On 09/01/2015 05:21 AM, Eric S. Raymond wrote:
Jason Merrill :
Given git aliases:
stamp = show -s --format='%cI!%ce'
scommit = "!f(){ d=${1%%!*}; a=${1##*!}; arg=\"--until=$d -1\"; if [ $a != $1 ]; then
arg=\"$arg --committer=$a\"; fi; shift; git rev-list $arg ${1:+\"$@\"}; };
On Tue, Sep 1, 2015 at 10:26 AM, Mikhail Maltsev wrote:
> On 09/01/2015 01:54 PM, Eric S. Raymond wrote:
>> With the machinery for the git conversion now in reasonable shape, it's
>> time to ask GCC's developers in general: what do you want this
>> conversion to accomplish?
> There was some discu
On Fri, 28 Aug 2015 17:50:53 +
Joseph Myers wrote:
> shinwell = Mark Shinwell
> (Jane Street)
Mark's current address is mshinw...@janestreet.com.
Julian
On 01/09/15 15:26, Mikhail Maltsev wrote:
> On 09/01/2015 01:54 PM, Eric S. Raymond wrote:
>> With the machinery for the git conversion now in reasonable shape, it's
>> time to ask GCC's developers in general: what do you want this
>> conversion to accomplish?
> There was some discussion concernin
On 1 September 2015 at 10:21, Eric S. Raymond wrote:
> Jason Merrill :
>> Given git aliases:
>>
>> >stamp = show -s --format='%cI!%ce'
>> >scommit = "!f(){ d=${1%%!*}; a=${1##*!}; arg=\"--until=$d -1\"; if
>> > [ $a != $1 ]; then arg=\"$arg --committer=$a\"; fi; shift; git rev-list
On 09/01/2015 01:54 PM, Eric S. Raymond wrote:
> With the machinery for the git conversion now in reasonable shape, it's
> time to ask GCC's developers in general: what do you want this
> conversion to accomplish?
There was some discussion concerning file renaming:
https://gcc.gnu.org/ml/gcc/2015-
Sebastian Huber writes:
> Thanks for this hint. Do you know the magic to use more than one machine
> option, e.g. -march=armv7-a -mthumb?
RUNTESTFLAGS=--target_board=unix\{,-march=armv7-a/-mthumb\}
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970
On 01/09/15 14:22, Andreas Schwab wrote:
Sebastian Huber writes:
How do the other ARM testers tackle this issue? Would it be possible to
add for example a "-march=armv7-a" option if the target selector contains
"arm"?
RUNTESTFLAGS=--target_board=unix\{,-march=armv7-a\}
Thanks for this hin
On Tue, 1 Sep 2015, Jan Hubicka wrote:
> > On Tue, 1 Sep 2015, Jan Hubicka wrote:
> >
> > > > > Yep, this looks like a resonable direction. It will break the one
> > > > > declaration
> > > > > rule in a more wild sense than current frontends does so, because if
> > > > > a builtin
> > > > > wi
On Tue, 2015-09-01 at 06:54 -0400, Eric S. Raymond wrote:
> With the machinery for the git conversion now in reasonable shape, it's
> time to ask GCC's developers in general: what do you want this
> conversion to accomplish?
>
> There are some obvious things we might expect it to accomplish, like
> On Tue, 1 Sep 2015, Jan Hubicka wrote:
>
> > > > Yep, this looks like a resonable direction. It will break the one
> > > > declaration
> > > > rule in a more wild sense than current frontends does so, because if a
> > > > builtin
> > > > win as a prevailing declaration, we end up with no mergi
Joseph Myers writes:
> On Tue, 1 Sep 2015, Eric S. Raymond wrote:
>
>> As a trivial example of the possibilities, sometimes when I do conversions
>> I fix obvious comment typos. I generally have to edit the comment history
>> anyway
>> to tweak comments that don't have git-style summary lines int
On Tue, 1 Sep 2015, Eric S. Raymond wrote:
> As a trivial example of the possibilities, sometimes when I do conversions
> I fix obvious comment typos. I generally have to edit the comment history
> anyway
> to tweak comments that don't have git-style summary lines into shape, so
> fixing typos is
Sebastian Huber writes:
> How do the other ARM testers tackle this issue? Would it be possible to
> add for example a "-march=armv7-a" option if the target selector contains
> "arm"?
RUNTESTFLAGS=--target_board=unix\{,-march=armv7-a\}
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG
On Tue, 1 Sep 2015, Jan Hubicka wrote:
> > > Yep, this looks like a resonable direction. It will break the one
> > > declaration
> > > rule in a more wild sense than current frontends does so, because if a
> > > builtin
> > > win as a prevailing declaration, we end up with no merging at all.
> >
Hello,
I would like to run as many tests as possible on the arm-rtems target.
Unfortunately about 100 tests use this:
// { dg-require-atomic-builtins "" }
Which uses a function check_v3_target_atomic_builtins in libstdc++.exp,
which uses this program to determine if the atomic builtins are a
> > Yep, this looks like a resonable direction. It will break the one
> > declaration
> > rule in a more wild sense than current frontends does so, because if a
> > builtin
> > win as a prevailing declaration, we end up with no merging at all.
> > I wonder if we don't want to always prevail to fi
With the machinery for the git conversion now in reasonable shape, it's
time to ask GCC's developers in general: what do you want this
conversion to accomplish?
There are some obvious things we might expect it to accomplish, like
(1) Encouraging people to do finer-grained commits because the ope
Jason Merrill :
> Given git aliases:
>
> >stamp = show -s --format='%cI!%ce'
> >scommit = "!f(){ d=${1%%!*}; a=${1##*!}; arg=\"--until=$d -1\"; if [
> > $a != $1 ]; then arg=\"$arg --committer=$a\"; fi; shift; git rev-list $arg
> > ${1:+\"$@\"}; }; f"
> >smaster = "!f(){
Hello,
in this test case there are two bool test variables (global and local).
Is this intentional?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains
Steve Ellcey schrieb:
I have a question about gengtype and GTY. I was looking at adding some
code to mips.c and it occurred to me that that file was getting very
large (19873 lines). So I wanted to add a new .c file instead but that
file needed some types that were defined in mips.c and not in
Rainer Orth :
> The current entry
>
> ro = Rainer Orth
>
> lists my old email address. Please use r...@cebitec.uni-bielefeld.de
> instead.
Done.
--
http://www.catb.org/~esr/";>Eric S. Raymond
Given this test case for rl78-elf:
extern __far int a, b;
void ffr (int x)
{
a = b + x;
}
I'm trying to use this patch:
Index: gcc/config/rl78/rl78-virt.md
===
--- gcc/config/rl78/rl78-virt.md (revision 227360)
+++ gcc/confi
"Steve Ellcey " writes:
> I have a question about gengtype and GTY. I was looking at adding some
> code to mips.c and it occurred to me that that file was getting very
> large (19873 lines). So I wanted to add a new .c file instead but that
> file needed some types that were defined in mips.c an
59 matches
Mail list logo