> for over a week, so do not know when this was introduced...
>
> This was introduced by:
> 2006-11-01 Pete Steinmetz <[EMAIL PROTECTED]>
> Peter Bergner <[EMAIL PROTECTED]>
>
> * doc/invoke.texi: Add cpu_type power6x
>
> The function
On Tue, Nov 07, 2006 at 11:36:00PM -0600, Peter Bergner wrote:
> The parallel that is causing the ICE is a store with update RTL insn.
> It seems like we should detect that and reach into the parallel and
> grab the actual store insn. I'll look into adding that.
I'm testing t
the idea: "Register allocation method
and apparatus for truncating runaway lifetimes of program variables
in a computer system". I have no idea whether this was one of the
patents made available by IBM for use by the OSS community or not.
Peter
--
Peter Bergner
Linux on Power Toolchain
IBM Linux Technology Center
On Wed, 2005-08-24 at 00:07 -0400, Daniel Berlin wrote:
> I imagine if you have 300k bb's or 1.5 million live pseudos to consider,
> it probably makes a real difference, but that's not *too* common in our
> supported languages (30k bb's/150k pseudos is probably the practical
> upper limit of what w
On Thu, 2005-11-17 at 11:53 -0500, Andrew MacLeod wrote:
> I have been contemplating building a GCC register allocator from scratch
> for some time. To that end, I have put together a bit of a document
> given a high level overview of the various components I think would
> benefit GCC, and a rough
On Tue, 2005-11-22 at 22:56 +0100, an unknown sender wrote:
> On Tuesday 22 November 2005 20:26, Peter Bergner wrote:
> > Insn Annotations [page(s) 17-18]:
> > * I like the idea of easy access to the register usage info
> > provided by the insn annotations. R
On Wed, 2005-11-23 at 15:05 +0100, Michael Matz wrote:
> > Spill Cost Engine [page(s) 26-29]:
> > * The register allocator should not be estimating the execution
> > frequency of a basic block as 10^nesting level. That information
> > should be coming from the cfg which comes from
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 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
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/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 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 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 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 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 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
> > >
> > >
> 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 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
> 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 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
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 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 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 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 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 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 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 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/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 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 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 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 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
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 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
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/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 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 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 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 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 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
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 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?
>
>
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/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/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/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 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
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 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
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 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-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 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 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 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 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 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 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 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 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 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 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 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
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 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
ith the tag
+ [ra-improvements] in the subject line. The branch
+ is maintained by mailto:[EMAIL PROTECTED]">Peter
+ Bergner.
Architecture-specific
On Thu, 2006-09-21 at 23:06 -0400, Jack Howarth wrote:
> Andrew,
> I've been trying to get a handle on why the line...
>
> frame = (StackFrame *)stack_start;
>
> in gcc/boehm-gc/darwin_stop_world.c only generates the warning...
>
> ../../../../gcc-4.2-20060920/boehm-gc/darwin_stop_world.
On Thu, 2006-09-21 at 23:54 -0400, Jack Howarth wrote:
> Peter,
> Wouldn't we want something like...
>
> +#ifdef __powerpc64__
> +unsigned long FindTopOfStack(unsigned long stack_start) {
> +#else
> unsigned long FindTopOfStack(unsigned int stack_start) {
> +#endif
Why have the #ifdef? Why
On Thu, 2006-09-21 at 23:54 -0400, Jack Howarth wrote:
> We have
> the same issue in gcc-4.2-20060915/libffi/src/powerpc/ffi_darwin.c
> (which might explain why it fails so many tests at -m64).
>
> http://gcc.gnu.org/ml/gcc/2006-09/msg00277.html
For this thread, you have:
*next_arg++ = (uns
On Fri, 2006-09-22 at 09:33 -0400, Jack Howarth wrote:
> Peter,
> Looking at the libffi/src/powerpc/ffi.c file, I assume that
> I should have the same...
>
>*next_arg++ = (unsigned long)(char *)ecif->rvalue;
>
> in ffi_darwin.c instead of the current...
>
>*next_arg++ = (unsigned)(ch
On Fri, 2006-09-22 at 08:53 -0500, Peter Bergner wrote:
> On Fri, 2006-09-22 at 09:33 -0400, Jack Howarth wrote:
> > Peter,
> > Looking at the libffi/src/powerpc/ffi.c file, I assume that
> > I should have the same...
> >
> >*next_arg++ = (unsigned long)
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 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
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 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 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 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 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-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 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 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-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 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, 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 Sun, 2007-12-30 at 10:16 +0100, Gerald Pfeifer wrote:
> At http://www.gnu.org/software/gcc/extensions.html we have a reference
> to the DLX port of GCC, which corresponds to the DLX machine described
> in "Computer Architecture: A Quantitative Approach" by Hennessy and
> Patterson.
>
> Sadly,
On Wed, 2008-01-23 at 12:06 +0100, Richard Guenther wrote:
> As we now reached the goal of less than 100 open serious regressions
> against GCC 4.3, we are as of now in regression and documentation fixes
> only mode. This means that for patches going on the trunk the same
> rules as for release br
On Sat, 2008-01-26 at 08:39 -0800, David Daney wrote:
> I have tried several times (and failed) to run the GCC testsuite on
> multilib targets (x86-64 and mips64) and have not been able to figure
> out how to get more that a single multilib configuration to be tested.
> The instructions on http:/
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
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 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 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 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 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 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 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 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 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-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
1 - 100 of 120 matches
Mail list logo
