On 3/8/24 5:28 PM, Jonathan Wakely wrote:
> On Fri, 8 Mar 2024 at 22:35, Frank Scheiner via Gcc wrote:
>>
>> On 08.03.24 23:00, Peter Bergner wrote:
>>> On 3/8/24 7:16 AM, Richard Biener via Gcc wrote:
>>>> I CCed Jeff who is on the commitee to forward the mai
On 3/8/24 5:30 AM, Jonathan Wakely via Gcc wrote:
> Patches should be sent to the gcc-patches list instead of this one,
> and should be against trunk not an old gcc-11 RC. See
> https://gcc.gnu.org/contribute.html#patches for more details - thanks!
And you need to CC the rs6000/powerpc port mainta
On 3/8/24 7:16 AM, Richard Biener via Gcc wrote:
> I CCed Jeff who is on the commitee to forward the maintainer proposal
> though I guess this will not go forward as a first step. Instead
> you are probably expected to show activity on the port, for example
> post the patch series to make ia64 use
On 5/20/22 12:15 AM, Nicholas Piggin via Gcc wrote:
> +PPC_FEATURE_HAS_ALTIVEC
> +Vector (aka Altivec, VSX) facility is available.
Slight typo. s/VSX/VMX/
Peter
On 12/4/21 11:40 AM, Thomas Koenig wrote:
> OK, what I have now is
>
> tkoenig@gcc-fortran:~$ echo $PATH
> /home/tkoenig/bin:/opt/at15.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
> tkoenig@gcc-fortran:~$ echo $LD_LIBRARY_PATH
> /home/tko
On 12/4/21 10:19 AM, Jakub Jelinek wrote:
> But when Thomas is working on the vanilla gcc tree, trying to make it work
> for Fortran, I think he'll need to patch that gcc tree too to use the
> AT15's dynamic linker and rpath like the AT15 gcc is.
That is part of the magic that happens when you con
On 12/4/21 9:37 AM, Peter Bergner wrote:
> On 12/4/21 9:25 AM, Michael Meissner wrote:
> ubuntu@gcc-fortran:/home/tkoenig/Tst$ ldd ./a.out
> ./a.out: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
> (required by ./a.out)
> linux-vdso64.so.1
On 12/4/21 9:25 AM, Michael Meissner wrote:
> On Sat, Dec 04, 2021 at 02:42:13PM +0100, Thomas Koenig wrote:
> Note, the system ldd does not tend to accurately report the library
> dependencies for AT libraries:
And using AT15's ldd, it shows your a.out is linked to the correct libc:
ubuntu@gcc-f
On 11/19/21 1:28 AM, Jojo R via Gcc wrote:
> We know gcc supply earlyclobber function to avoid register overlap,
>
> but it can not describe explicitly for specific source operand, is it
> right ?
You add the early clobber to the OUTPUT operand(s) that can clobber any of the
input so
On 10/6/21 12:50 PM, Segher Boessenkool wrote:
> So we have three options (well, four):
>
> 0) Do nothing. We will stay in this hell forever. Not my choice :-)
> 1) Use a soft-float-like parameter passing everywhere. This works but
>will be horridly slow on newer systems. We can do better
On 6/16/21 1:32 PM, Uros Bizjak wrote:
> On Wed, Jun 16, 2021 at 6:08 PM Liu Hao wrote:
>> It looks like Uroš was on 00d07ec6e12, committed his changes mistakenly with
>> `git commit --amend`
>> (which changed the commit message but did not reset the author), then
>> rebased the modified commit
uthor when
committing that, so we're wondering whether there might be a bug in one
of the commit hooks. Is there someone who an dig into the commit below
and try to find out how the author field was incorrectly set?
Peter
commit a325bdd195ee96f826b208c3afb9bed2ec077e12
Author: Pet
On 4/20/21 4:20 PM, Jakub Jelinek via Gcc wrote:
> On Tue, Apr 20, 2021 at 03:27:08PM -0500, William Seurer via Gcc wrote:
>> /tmp/cc8zG8DV.s: Assembler messages:
>> /tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13
>> /tmp/cc8zG8DV.s:2570: Error: unsupported relocation against r14
[s
On 3/24/20 12:06 PM, Frank Ch. Eigler wrote:
>> Thanks for working on this!!! However, I still see at least one issue
>> in the following bugzilla entry:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94123#c4
>>
>> The first two git style links work, but the last one which points
>> to th
On 3/20/20 12:37 PM, Frank Ch. Eigler via Gcc wrote:
> Hi -
>
> Both svn: and ssh+svn: now work for your archeological needs.
> Further, URLs such as
>
> https://gcc.gnu.org/viewcvs?rev=279160&root=gcc&view=rev
> https://gcc.gnu.org/r123456
>
> are mapped to gitweb searches that try to locate th
On 1/23/20 12:09 PM, Peter Bergner wrote:
> On 1/23/20 4:29 AM, Jakub Jelinek wrote:
>> so it is not a fast forward merge and we have the requirement that
>> From-SVN: shouldn't appear in commit logs of new commits.
>
> So I just did "git merge releases/gcc-9"
On 1/23/20 4:29 AM, Jakub Jelinek wrote:
> Just FYI if somebody needs to do something similar, I needed to do a merge
> from origin/releases/gcc-9 to our vendor branch -
> refs/vendors/redhat/heads/gcc-9-branch
> This branch has some extra commits origin/releases/gcc-9 branch doesn't
> have,
This
On 1/22/20 3:26 AM, Gerald Pfeifer wrote:
> On Mon, 13 Jan 2020, Joseph Myers wrote:
>> In addition, once git.html is more complete (has the list of branches
>> added, at least) we need to update the GCC home page to link to the new
>> pages in place of those for SVN, redirect the old pages to th
As somewhat of a git newbie and given gcc developers will do a git push of
our changes rather than employing a git pull development model, I'd like
a little hand holding on what my new gcc git workflow should be, so I don't
screw up the upstream repo by pushing something to the wrong place. :-)
I
On 10/30/19 2:31 PM, Georg-Johann Lay wrote:
> Hi, have the cc0 backends been deprecated?
>
> I didn't follow the lists for some time... At least neither v9 or v10
> release notes caveats mention such deprecation, neither is there
> respective PRs for the cc0 targets.
https://gcc.gnu.org/ml/gcc-
On 2/20/19 9:39 PM, Alan Modra wrote:
> On Wed, Feb 20, 2019 at 08:57:52PM -0600, Peter Bergner wrote:
>> Yes, because they don't have my IRA and LRA patches that exposed this
>> problem. I would say they were buggy for not complaining and silently
>> spilling a hard reg
On 2/20/19 4:04 PM, Alan Modra wrote:
> On Wed, Feb 20, 2019 at 10:08:07AM -0600, Peter Bergner wrote:
>> On 2/19/19 9:09 PM, Alan Modra wrote:
>> That said, talking with Segher and Uli offline, they both think the
>> inline asm usage in the test case should be legal
>
&g
On 2/20/19 4:19 PM, Alan Modra wrote:
> I forgot to say, gcc-6, gcc-7 and gcc-8 handle your original testcase
> with the register asm just fine.
Yes, because they don't have my IRA and LRA patches that exposed this
problem. I would say they were buggy for not complaining and silently
spilling a ha
On 2/19/19 9:09 PM, Alan Modra wrote:
> On Mon, Feb 18, 2019 at 01:13:31PM -0600, Peter Bergner wrote:
>> long input;
>> long
>> bug (void)
>> {
>> register long output asm ("r3");
>> asm ("blah %0, %1, %2" : "=&r" (outp
I have a question about constraint usage in inline asm when we have
an early clobber output operand. The test case is from PR89313 and
looks like the code below (I'm using "r3" for the reg on ppc, but
you could also use "rax" on x86_64, etc.).
long input;
long
bug (void)
{
register long output
On 12/19/18 7:59 AM, Florian Weimer wrote:
> * Richard Biener:
>
>> Sure, if we'd ever deploy this in production placing this in the
>> TCB for glibc targets might be beneifical. But as said the
>> current implementation was just an experiment intended to be
>> maximum portable. I suppose the dy
On 11/1/18 10:37 PM, Vladimir Makarov wrote:
> On 11/01/2018 08:25 PM, Paul Koning wrote:
>> Is this an LRA bug, or is there something I need to do in the target to
>> prevent this happening?
> It is hard to say whose code is responsible for this. It might be a wrong
> machine-dependent code or
On 11/1/18 8:40 PM, Segher Boessenkool wrote:
> Hi Peter,
>
> On Thu, Nov 01, 2018 at 07:49:36PM -0500, Peter Bergner wrote:
>> On 11/1/18 7:25 PM, Paul Koning wrote:
>>> I'm running the testsuite on the pdp11 target, and I get a failure when
>>> using
On 11/1/18 7:25 PM, Paul Koning wrote:
> I'm running the testsuite on the pdp11 target, and I get a failure when using
> LRA that works correctly with the old allocator. The issue is that LRA is
> producing an insn that is invalid (it violates the constraints stated in the
> insn definition).
[
On 8/31/18 10:41 AM, Matthew Malcomson wrote:
> I'm looking into whether it's possible to require even numbered registers on
> modes that need more than one hard-register to represent them. But only in
> some cases.
Yes, it's possible. You can look at TDmode (128-bit decimal floating point)
on po
On 8/27/18 1:20 PM, sameeran joshi wrote:
> On 8/27/18, Peter Bergner wrote:
>> On 8/27/18 12:13 PM, sameeran joshi wrote:
>>> On 8/27/18, Peter Bergner wrote:
>>>> Well what does:
>>>>
>>>> linux% gcc -I/home/swamimauli/upload/csmith
On 8/27/18 12:13 PM, sameeran joshi wrote:
> On 8/27/18, Peter Bergner wrote:
>> Well what does:
>>
>> linux% gcc -I/home/swamimauli/upload/csmith/runtime/ -Wall bug.c
>
> running above command on terminal,gives many warnings and asks for the
> -fgnu-tm op
On 8/27/18 11:42 AM, sameeran joshi wrote:
> It's still giving output as 1,I included the -squiggle option still,it
> dosen't work for me? any Ideas?
>
> #!/bin/bash
>
> CC="-I/home/swamimauli/upload/csmith/runtime/"
> OPTS="-Wall"
> TEST="bug.c"
> gcc ${CC} ${OPTS} ${TEST} 2>&1 | grep 'internal
On 8/27/18 10:35 AM, Shubham Narlawar wrote:
> Here is the file. I am getting some error in sending .sh file, so I send it
> as below.
>
> #!/bin/bash
> gcc -fgnu-tm testcase.c > out.txt 2>&1 &&\
> if
> grep 'internal compiler error' out.txt
> then
> exit 0
> else
> exit 1
> fi
When I
On 6/26/18 4:05 AM, Peryt, Sebastian wrote:
> With some changes simplified implementation of my expansion is as follows:
> tmp_op0 = gen_reg_rtx (mode);
> emit_move_insn (tmp_op0, op0);
You set tmp_op0 here, and then
> emit_insn (gen_rtx_SET (tmp_op0, reg));
You set it again here without ev
On 3/5/18 9:33 AM, Segher Boessenkool wrote:
> On Mon, Mar 05, 2018 at 08:01:14AM +0100, Eric Botcazou wrote:
>> Apparently the authors of the SPARC psABI thought that the last part of your
>> sentence is an interpolation and that the (historical) requirements were
>> vague
>> enough to allow th
On 3/4/18 7:57 AM, Eric Botcazou wrote:
>> I can't argue with anything in that comment, other than the conclusion. :-)
>> It's not the compiler's job to implement the setjmp/longjmp save/restore.
>> Maybe Kenny was working around a problem with some target's buggy setjmp
>> and spilling everything
On 3/3/18 5:47 PM, Peter Bergner wrote:
> On 3/3/18 10:29 AM, Jeff Law wrote:
>> Here's the comment from regstat.c:
>>
>> /* We have a problem with any pseudoreg that lives
>> across the setjmp. ANSI says that if a user variable
>
On 3/3/18 10:29 AM, Jeff Law wrote:
> Here's the comment from regstat.c:
>
> /* We have a problem with any pseudoreg that lives
> across the setjmp. ANSI says that if a user variable
> does not change in value between the setjmp and the
>
On 3/2/18 3:26 PM, Jeff Law wrote:
> On 03/02/2018 12:45 PM, Peter Bergner wrote:
>> ...which forces us to spill everything live across the setjmp by forcing
>> the pseudos to interfere all hardregs. That can't be good for performance.
>> What am I missing?
>
>
While debugging the PR84264 ICE caused by the following test case:
void _setjmp ();
void a (unsigned long *);
void
b ()
{
for (;;)
{
_setjmp ();
unsigned long args[9]{};
a (args);
}
}
I noticed that IRA is spilling all pseudos that are live acro
On 12/14/17 9:18 PM, Leslie Zhai wrote:
> * The papers by Briggs and Chaiten contradict[2] themselves when examine
> the text of the paper vs. the pseudocode provided?
I've read both of these papers many times (in the past) and I don't recall
any contradictions in them. Can you (Dave?) be more sp
On 2/14/17 6:06 PM, Alan Modra wrote:
Since we've been talking about obsoleting cpu support, how about
getting rid of -many in ASM_CPU_SPEC for gcc-8?
+1
Peter
On 1/24/17 3:06 PM, Richard Henderson wrote:
The only possible concern I see might be with simulators that force HTM
failure, for the purpose of forcibly testing fallback paths. I guess we'd have
to continue to fall back to the lock path for that case.
IIRC, this was the path that valgrind was
On Fri, 2016-01-15 at 11:13 +0100, Richard Biener wrote:
> Btw, I'd like people to start thinking if the scheduling algorithms
> working on loops (and sometimes requiring unrolling of loops) can be
> implemented in a way to apply that unrolling on the GIMPLE level
> (not the scheduling itself of co
On Wed, 2015-12-02 at 20:05 -0500, Ryan Burn wrote:
> Is there any way to easily build a stage1 gcc with macro support for
> debugging?
>
> I tried setting CFLAGS, and CXXFLAGS to specify "-O0 -g3" via the
> command line before running configure, but that only includes those
> flags for some of t
On Wed, 2015-09-23 at 16:15 +0200, Sebastian Huber wrote:
> On 10/09/15 19:52, David Edelsohn wrote:
> > https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html
>
> Is there specific reason why the SYNC L,E (Elemental Memory Barriers)
> defined by Power-ISA V2.07 doesn't appear in this table?
Pro
On Fri, 2015-08-28 at 11:00 -0400, Eric S. Raymond wrote:
> Peter Bergner :
> > On Thu, 2015-08-27 at 10:38 -0400, Eric S. Raymond wrote:
> > > I've made it available at:
> > >
> > > http://thyrsus.com/gitweb/?p=gcc-conversion.git
> > >
> &g
> azanella = Adhemerval Zanella
Adhemerval now works for Linaro, so his email address should be:
adhemerval.zane...@linaro.org
> bje = Ben Elliston
Ben is no longer at Red Hat...or IBM. He went back to school and his
new email address seems to be:
b.ellis...@unsw.edu.au
>
On Thu, 2015-08-27 at 10:38 -0400, Eric S. Raymond wrote:
> I've made it available at:
>
> http://thyrsus.com/gitweb/?p=gcc-conversion.git
>
> The interesting content is gcc.map (the contributor map) and gcc.lift.
>
> Presently the only command in gcc.lift expunges the hooks directory.
>From yo
> these to emails yet.
> acsawdey
Aaron Sawdey / acsaw...@linux.vnet.ibm.com
> bergner
Peter Bergner / berg...@vnet.ibm.com
> boger
Lynn Boger ? labo...@linux.vnet.ibm.com
> pthaugen
Pat Haugen / pthau...@linux.vnet.ibm.com
> revitale
Revital Eres / e...@il.ibm.c
On Wed, 2015-08-26 at 20:12 -0400, Eric S. Raymond wrote:
> Peter Bergner :
> > On Wed, 2015-08-26 at 16:35 -0400, Eric S. Raymond wrote:
> > > Joseph Myers :
> > > > > irar = irar
> > > >
> > > > Ira Rosen
> > >
> > >
On Wed, 2015-08-26 at 18:55 -0500, Peter Bergner wrote:
> On Wed, 2015-08-26 at 16:35 -0400, Eric S. Raymond wrote:
> > Joseph Myers :
> > > > irar = irar
> > >
> > > Ira Rosen
> >
> > I pretty much knew these two guys went with these two
On Wed, 2015-08-26 at 13:44 -0700, Ian Lance Taylor wrote:
> On Wed, Aug 26, 2015 at 12:31 PM, Eric S. Raymond wrote:
> > click = click
>
> You've got me on that one. Any hints?
Just purely looking at the name, did Cliff Click ever
contribute to gcc in the past?
Peter
On Wed, 2015-08-26 at 16:35 -0400, Eric S. Raymond wrote:
> Joseph Myers :
> > > irar = irar
> >
> > Ira Rosen
>
> I pretty much knew these two guys went with these two names, but couldn't
> figure out which was which. Thanks.
Actually, Ira Rosen is a "she" and not a "he".
Peter
On Fri, 2015-08-21 at 16:09 +0200, Andreas Schwab wrote:
> Ramana Radhakrishnan writes:
>
> > On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely
> > wrote:
> >> Teams following a different model could use a separate repo shared by
> >> those developers, not the gcc.gnu.org one. It's much easier
On Tue, 2015-04-14 at 17:37 +0200, Harald Servat wrote:
> I'm trying to compile the GCC's trunk but I find out the following
> error while compiling it. I've configured it such as
This question is not appropriate for this mailing list, as this
list is only for questions about gcc development. Y
On Fri, 2013-11-22 at 12:30 +0100, Richard Biener wrote:
> On Fri, Nov 22, 2013 at 1:57 AM, Jonathan Wakely
> wrote:
> > Yes, it only seems to be a problem with SUSE kernels:
> > http://gcc.gnu.org/ml/gcc/2013-11/msg00090.html
>
> As my bugreport is being ignored it would help if one ouf our
> p
On Fri, 2013-11-08 at 00:03 +0100, Steven Bosscher wrote:
> powerpc64-linux bootstrap is broken by the libsanitizer merge:
I already reported the failures here:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00312.html
It seems others have reported it breaks bootstrap for them as
well on other
On Fri, 2013-09-06 at 13:36 +0200, Paolo Carlini wrote:
> . on x86_64-linux, this commit broke the build of that file:
>
> http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00149.html
>
> CC-ing Peter.
Can you try the patch that HJ suggested?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139#c9
Peter
On Wed, 2013-07-24 at 10:42 -0700, H.J. Lu wrote:
> Are there any other Linux targets with callee saved vector registers?
Yes, on POWER. From our ABI:
On processors with the VMX feature.
v0-v1 Volatile scratch registers
v2-v13 Volatile vector parameters registers
v14-v19 Volatile s
On Tue, 2013-06-18 at 21:48 +0200, Andi Kleen wrote:
> > Given Torvald's comment, can you verify whether your hw txn succeeds
> > (all the way to commit) or whether it is failing and somehow skips
> > the fall through code that is hanging for us (Power and S390)?
>
> All the 3 transactions in reen
On Tue, 2013-06-18 at 18:41 +0200, Torvald Riegel wrote:
> On Fri, 2013-06-14 at 19:44 -0500, Peter Bergner wrote:
> > I'll note that if I hack the call to
> > htm_abort_should_retry(ret) so that we break of of the loop and fallback
> > to SW TM, then the test case exe
On Tue, 2013-06-18 at 11:22 -0700, Andi Kleen wrote:
> Peter Bergner writes:
> >
> > I have yet to track down who has the write lock and why, but I am working
> > towards that. Talking with Andreas, he said he is seeing the same failure
> > on S390, so I'm w
I'm currently implementing support for hardware transactional memory in
the rs6000 backend for POWER8. Things seem to be mostly working, but I
have run into a few issues I'm wondering whether other people are seeing.
For me, all of the libitm execution test cases in libitm/testsuite/libitm.c/
com
On Mon, 2013-01-14 at 08:00 +0100, Thomas Baier wrote:
> The operating system I'd like to use gcc for (OS-9, for the curious)
> requires an ABI, where global variables are only accessed through
> register indirect addressing. On the powerpc platform, r2 is used for
> indirect addressing. There is a
On Wed, 2012-11-14 at 18:51 +0100, Andreas Tobler wrote:
> Hello,
>
> on trunk (193501) I get a comparison failure:
> ---
> Bootstrap comparison failure!
> gcc/tree-ssa-forwprop.o differs
> ---
>
> This is with --disable-checking. Leaving disable-checking away, the
> bootstrap completes succesful
On Mon, 2012-11-05 at 15:47 +0100, Jakub Jelinek wrote:
> On Mon, Nov 05, 2012 at 08:40:00AM -0600, Peter Bergner wrote:
> > Well we also patch config.in and configure.ac/configure. If those are
> > acceptable to be patched later too, then great. If not, the patch
>
> That
On Mon, 2012-11-05 at 13:53 +0100, Jakub Jelinek wrote:
> On Mon, Nov 05, 2012 at 06:41:47AM -0600, Peter Bergner wrote:
> > I'd like to post later today (hopefully this morning) a very minimal
> > configure patch that adds the -mcpu=power8 and -mtune=power8 compiler
> >
On Mon, 2012-10-29 at 18:56 +0100, Jakub Jelinek wrote:
> Status
> ==
>
> I'd like to close the stage 1 phase of GCC 4.8 development
> on Monday, November 5th. If you have still patches for new features you'd
> like to see in GCC 4.8, please post them for review soon. Patches
> posted before
On Wed, 2012-02-01 at 13:09 -0500, David Miller wrote:
> From: Michael Matz
> Date: Wed, 1 Feb 2012 18:41:05 +0100 (CET)
>
> > One problem is that it's not a new problem, GCC emitted similar code since
> > about forever, and still they turned up only now (well, probably because
> > ia64 is dead
On Fri, 2012-01-27 at 18:40 +0100, Michael Matz wrote:
> The hack below works in this specific situation (TERed into a switch), and
> adds a REG_EXPR when an TERed SSA name ever expanded into a pseudo (i.e.
> also for some more generic situations).
FYI, I bootstrapped and regtested your patch on
On Wed, 2012-01-11 at 12:29 -0500, Vladimir Makarov wrote:
> There is no visible effect of the patch on SPECFP2000 performance and
> size (the size increase is only about 0.02%) for x86 and x86-64.
>
> The patch does worsen performance of SPECINT2000 on x86 (about 0.5%) and
> x86-64 (about 0.3%)
On Tue, 2012-01-10 at 12:20 -0500, Vladimir Makarov wrote:
> > Do we really need or want to create shuffle copies for insns that do not
> > have a two operand constraint?
> Yes, I think so. As I remember I did some benchmarking and it gave some
> "order" in hard register assignments and improved
Hi Vlad,
While debugging a slightly modified version of the test case in PR16458:
int
foo (unsigned int a, unsigned int b)
{
if (a == b) return 1;
if (a > b) return 2;
if (a < b) return 3;
if (a != b) return 4;
return 0;
}
I noticed a couple of ugly code gen warts w
On Sat, 2010-11-13 at 11:27 +0100, Paolo Bonzini wrote:
> On 11/12/2010 03:25 PM, H.J. Lu wrote:
> > IRA may move instructions across an unspec_volatile,
>
> Do you have a testcase?
Are you sure it's IRA and not our old friend update_equiv_regs()
which IRA calls? http://gcc.gnu.org/PR41171 shows
latOn Mon, 2010-11-08 at 21:13 +, Dave Korn wrote:
> On 08/11/2010 13:44, Joakim Tjernlund wrote:
> > One ping and a few days later and nothing. Very frustrating. I don't
> > believe all PPC devs are so "busy" that none has the time to look
> > at a simple one liner. What is up?
>
> There's
On Fri, 2010-08-06 at 12:27 -0700, Erick Garske wrote:
> There a location where I can download the binary of GCC for the IBM i?
>
> http://gcc.gnu.org/install/binaries.html
>
> Are any of these compatible for the IBM i at V6R1M0?
There is no support in GCC for native iSeries (AKA AS/400).
Pete
On Thu, 2010-06-24 at 08:57 -0600, Jeff Law wrote:
> On 06/24/10 02:02, Revital1 Eres wrote:
> > Hello,
> >
> > In the new target I'm working on there are branch regs and gprs.
> > The loads and store instructions are only to/from the gprs, so if a
> > branch reg needs to be spilled it first needs
On Wed, 2009-09-02 at 11:49 -0400, Vladimir Makarov wrote:
> So probably, it is worth to do update_equiv_reg as a separate pass.
Agreed.
> I'll submit a patch on next week (sorry, I am a bit busy this week).
Sounds good. Thanks for taking care of this!
Peter
On Tue, 2009-09-01 at 16:46 -0400, Vladimir Makarov wrote:
> Peter Bergner wrote:
> > Were you going to whip that patch up or did you want me to?
> >
> I am going to do it by myself.
Great! I'd like to see how your patch affects POWER6 performance.
Do you have access t
On Tue, 2009-09-01 at 10:38 -0400, Vladimir Makarov wrote:
> We could do update_equiv_regs in a separate pass before the 1st insn
> scheduling as it was before IRA.
IIRC, update_equiv_regs() was always called as part of local-alloc,
so it was always after sched1 even before IRA. That said, movin
On Wed, 2009-08-26 at 17:12 -0500, Peter Bergner wrote:
> On Wed, 2009-08-26 at 23:30 +0200, Richard Guenther wrote:
> > Hmm. I suppose if you conditionalize it on flag_schedule_insns it might be
> > an overall win. Care to SPEC test that change?
>
> I assume you mean
On Wed, 2009-08-26 at 23:30 +0200, Richard Guenther wrote:
> On Wed, Aug 26, 2009 at 10:47 PM, Peter Bergner wrote:
> > Looking at update_equiv_regs(), if I disable the replacement for regs
> > that are local to one basic block (patch below) like it existed before
> > John W
On Mon, 2009-08-24 at 23:56 +, Charles J. Tabony wrote:
> I am seeing a performance regression on the port I maintain, and I would
> appreciate some pointers.
>
> When I compile the following code
>
> void f(int *x, int *y){
> *x = 7;
> *y = 4;
> }
>
> with GCC 4.3.2, I get the desired
On Thu, 2009-07-16 at 13:55 -0700, Michael Eager wrote:
> I've tracked down a failure in gdb to hit a breakpoint
> set at printf to the the breakpoint being placed incorrectly.
>
> Here is the code generated for printf with -mhard-float:
>
> .loc 1 29 0
> .cfi_startproc
> .LVL0:
>
On Sat, 2009-06-20 at 17:01 +0200, Richard Guenther wrote:
> On Sat, Jun 20, 2009 at 4:54 PM, Jeff Law wrote:
> >
> > Imagine a loop like this
> >
> > EXECUTE_IF_SET_IN_BITMAP (something, 0, i, bi)
> > {
> > bitmap_clear_bit (something, i)
> > [ ... whatever code we want to process i, ... ]
>
On Sat, 2008-10-04 at 18:48 +0200, Gerald Pfeifer wrote:
> Thanks for the background on this, Peter, and the background on this
> site disappearing.
>
> The reason I asked was that we have that reference from our site to that
> URL and I failed to find any replacement so far. The first two hits t
On Fri, 2008-09-19 at 09:41 +1000, Ben Elliston wrote:
> On Thu, 2008-09-18 at 10:44 -0600, Tom Tromey wrote:
> > Yeah, this seems necessary. Ideally the order ought to be stable, too.
>
> Do you think that the current order of .exps should be preserved in the
> resultant .sum and .logs? I guess
On Thu, 2008-09-04 at 20:28 -0400, David Edelsohn wrote:
> On Thu, Sep 4, 2008 at 7:39 PM, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
> > Meanwhile I am going to submit your second patch with an added
> > comment. The patch permits gcc to generate the same quality code as
> > before your first pa
On Thu, 2008-07-24 at 18:48 +0200, Andreas Schwab wrote:
> Definitely something fishy around that time. svn log says:
>
>
> r138082 | meissner | 2008-07-23 13:18:03 +0200 (Mi, 23 Jul 2008) | 1 line
>
> Add missing ChangeLog
On Thu, 2008-05-08 at 11:38 -0700, Steve Ellcey wrote:
> The psuedo for %r8 does have REG_POINTER set and the psuedo for %r19
> does not. I first see REG_POINTER set for ivtmp___1536 (the psuedo for
> %r8) in flow.c.138r.loop2_invariant. This seems interesting because
> Peter's patch, that fixes
On Wed, 2008-05-07 at 11:03 -0700, Steve Ellcey wrote:
> > Can you please also add the replacement hunk from:
> >
> > o;?http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00693.html
> >
> > If the first part gets backported, I'd like the second hunk to
> > go along with it if possible. Thanks.
> >
On Wed, 2008-05-07 at 10:10 -0700, Steve Ellcey wrote:
> Yes, it looks like it is. I added -fno-strict-aliasing and the perl
> benchmarks passed when compiled with ToT GCC. That makes me feel better
> about the idea of putting Peter's patch (with the revert) on the 4.3
> branch as a way to fix th
On Wed, 2008-05-07 at 07:45 -0700, Steve Ellcey wrote:
> I have found that this problem does not occur on the ToT sources and
> that the problem went away with this patch:
>
> 2008-04-07 Peter Bergner <[EMAIL PROTECTED]>
>
>PR middle-end/PR28690
>*
On Mon, 2008-04-28 at 18:07 -0400, Vladimir Makarov wrote:
> I am currently working on bit matrix compression. It is not implemented
> yet. I hope it will be ready in a week.
Ahh, ok. Well, hopefully the code I wrote on the trunk is useful for IRA.
If you have questions about it, let me know,
On Mon, 2008-04-28 at 16:01 -0400, Vladimir Makarov wrote:
> Thanks, Peter. That was clever and email is very enlightening. I have
> analogous idea for more compact conflict matrix representation. IRA
> builds allocno live ranges first (they are ranges of program points
> where the allocno li
On Thu, 2008-04-24 at 20:23 -0400, Vladimir Makarov wrote:
> Hi, Peter. The last time I looked at the conflict builder
> (ra-conflict.c), I did not see the compressed matrix. Is it in the
> trunk? What should I look at?
Yes, the compressed bit matrix was committed as revision 129037 on
Octobe
On Thu, 2008-04-24 at 16:33 -0500, Peter Bergner wrote:
> On Thu, 2008-04-24 at 16:51 +0200, Paolo Bonzini wrote:
> > >> (The testcase is 400k lines of preprocessed Fortran code, 16M is size,
> > >> available here:
> > >> http://www.pci.unizh.ch/va
On Thu, 2008-04-24 at 16:51 +0200, Paolo Bonzini wrote:
> >> (The testcase is 400k lines of preprocessed Fortran code, 16M is size,
> >> available here:
> >> http://www.pci.unizh.ch/vandevondele/tmp/all_cp2k_gfortran.f90.gz)
> >>
> >>
> > Thanks, I'll check it.
>
> Vlad, I think you should also
1 - 100 of 120 matches
Mail list logo
