"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
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
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
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
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
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(){
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
> > 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
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
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.
> >
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, 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
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, 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
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:
> > 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 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
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 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-
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 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 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 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 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:+\"$@\"}; };
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
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
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
"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
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.
>
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 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 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
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
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
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
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 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 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
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
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
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
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-
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 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
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
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
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
> 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 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
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 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 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 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 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 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 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 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: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 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
59 matches
Mail list logo
