On 4/23/20 8:31 AM, Eric Botcazou wrote:
Thanks, I will take a look at Bernd's work. IIRC, he took a
different approach from what was suggested in the wiki, right?
Yes, let's say that it's a half-baked conversion, probably a consequence of
the bounty. This might be good enough, depending on th
On 3/18/20 3:22 PM, Frank Ch. Eigler via Gcc wrote:
The From: header rewriting for DMARC participants is something sourceware
is doing now.
Out of curiousity, is this rewriting you are talking about the cause for
a lot of mails showing up as "From: GCC List" rather than their real
senders? Th
On 1/10/20 8:33 AM, Maxim Kuvyrkov wrote:
Joseph, please point to message on gcc@ mailing list that expresses consensus
of GCC community to use reposurgeon conversion. Otherwise, it is not
appropriate to substitute one's opinion for community consensus.
I was on the fence for a long time, si
On 12/18/19 10:55 PM, Joseph Myers wrote:
git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-3a.git
I cloned this one and started trying random things again.
The previous one had some strange-looking merge commits, but it sounded
like that was a known issue, and indeed the ones I had seen wer
On 12/17/19 10:32 PM, Joseph Myers wrote:
git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-1a.git
It seems that permission bits are not reproduced entirely correctly. For
example, contrib/check_GNU_style_lib.py went from -rwxr-xr-x in svn (and
the git-svn repository) to -rw-r--r-- in this
On 12/9/19 7:19 PM, Joseph Myers wrote:
For any conversion we're clearly going to need to run various validation
(comparing properties of the converted repository, such as contents at
branch tips, with expected values of those properties based on the SVN
repository) and fix issues shown up by th
On 12/6/19 6:21 PM, Eric S. Raymond wrote:
Your approach sounds pretty reasonable except for that part. I don't
trust git-svn at *all* - I've collided with it too often during
past conversions. It has a nasty habit of leaving damage in places
that are difficult to audit.
So, which steps are w
On 07/09/2018 09:19 PM, Eric S. Raymond wrote:
> Last time I did a comparison between SVN head and the git conversion
> tip they matched exactly. This time I have mismatches in the following
> files.
So what are the diffs? Are we talking about small differences (like one
change missing) or large-
On 05/15/2018 12:58 PM, A. Skrobov wrote:
>>> That makes me wonder if there is a latent bug though. Consider pushing
>>> args to a pure function. Could we then try to CSE the memory reference
>>> and get it wrong because we haven't accounted for the autoinc?
>>
>> Can't know for sure but one woul
On 05/14/2018 10:55 PM, Jeff Law wrote:
> That does sound vaguely familiar. Did we put autoinc notes on the stack
> pushes?
Not as far as I recall. I only see REG_ARGS_SIZE notes in the dumps.
> That makes me wonder if there is a latent bug though. Consider pushing
> args to a pure function. C
On 05/12/2018 07:01 PM, Jeff Law wrote:
> No. We're not supposed to have any auto-inc insns prior to the auto-inc
> pass. A stack push/pop early in the compiler would have to be
> represented by a PARALLEL.
>
> It's been this way forever. It's documented in the internals manual
> somewhere.
S
On 07/10/2017 05:10 PM, Georg-Johann Lay wrote:
> (set (zero_extract:QI (reg/i:QI 24 r24)
> (const_int 1 [0x1])
> (const_int 6 [0x6]))
> (lshiftrt:QI (reg:QI 52)
> (const_int 6 [0x6])))
> The problem is that the backend only sees
>
> avr_rtx_costs[bset:combine(266)]=tr
On 03/17/2017 07:38 PM, Pinski, Andrew wrote:
One of the following revision caused a bootstrap comparison failure on
aarch64-linux-gnu:
r246225
r246226
r246227
Can you help narrow that down?
Bernd
On 02/17/2017 02:09 PM, Thomas Schwinge wrote:
Hi!
On Fri, 17 Feb 2017 14:00:09 +0100, I wrote:
[...] for "normal" functions there is no reason to use the
".param" space for passing arguments in and out of functions. We can
then get rid of the boilerplate code to move ".param %in_ar*" into ".r
On 10/14/2016 11:26 AM, Richard Biener wrote:
On Fri, Oct 14, 2016 at 11:15 AM, Bernd Schmidt wrote:
So maybe it should just call clear_bb_flags instead of doing the loop
itself? Ok if that works.
That doesn't generally work, it clears too many flags (it was appearantly
designed fo
On 10/14/2016 10:01 AM, Thomas Schwinge wrote:
After the "Add Early VRP" GCC trunk commit r240291 (Kugan CC for your
information), I've been observing all kinds of OpenACC offloading
failures. I now figured out what's going on.
The "evrp" pass uses basic_block's BB_VISITED flag. It first clear
On 10/04/2016 12:41 PM, Jonathan Wakely wrote:
On 4 October 2016 at 10:21, David Brown wrote:
On 04/10/16 01:48, Martin Sebor wrote:
In a recent review Jason and I discussed the style convention
commonly followed in the C++ front end to annotate arguments
in calls to functions taking bool param
On 08/04/2016 04:49 PM, Thomas Schwinge wrote:
Global Reviewers are welcome to review OpenACC/OpenMP/offloading patches.
But that doesn't help if that's then not happening in reality. (With the
exception of Bernd, who then did review such patches for a while, but
also seems to have stopped with
On 03/25/2016 04:43 AM, Aldy Hernandez wrote:
If Bernd is fine with this, I'm happy to retract my patch and any
possible followups. I'm just interested in having no path causing a
possible out of bounds access. If your patch will do that, I'm cool.
I'll need to see that patch first to comment
On 03/24/2016 11:17 AM, Aldy Hernandez wrote:
On 03/23/2016 10:25 AM, Bernd Schmidt wrote:
It looks like this block of code is written by a helper function that is
really intended for other purposes than for maximal_insn_latency. Might
be worth changing to
int insn_code = dfa_insn_code
On 03/23/2016 07:32 AM, Aldy Hernandez wrote:
int
maximal_insn_latency (rtx insn)
{
int insn_code;
if (insn == 0)
insn_code = DFA__ADVANCE_CYCLE;
else
{
insn_code = dfa_insn_code (as_a (insn));
if (insn_code > DFA__ADVANCE_CYCLE)
return 0;
}
On 01/27/2016 12:12 AM, David Wohlferd wrote:
I started by just commenting out the code in ix86_md_asm_adjust that
unconditionally clobbered the flags. I figured this would allow the
'normal' "cc" handling to occur. But apparently there is no 'normal'
"cc" handling.
I have a dim memory that t
On 01/26/2016 10:48 AM, Bin.Cheng wrote:
Yes, I moved whole loop pass (also the pass_web) after combine and it
worked. A combine pass before loop-invariant can fix this problem.
Below passes are currently between loop transform and combine:
NEXT_PASS (pass_web);
NEXT_PASS (pass_rt
On 01/25/2016 08:51 PM, Jeff Law wrote:
No, the combiner works within a basic block only. There was a group, I
believe in Moscow, that worked on a cross-block combiner. It was
discussed at the Cauldron in California a few years back. I don't know
if they did any further work on those ideas.
I
On 01/15/2016 07:05 AM, Jeff Law wrote:
Well, you have to write the pattern and a splitter. But these days
there's define_insn_and_split to help with that. Reusing Bernd's work
may ultimately be easier though.
Maybe, but maybe also not in the way you think. I've always wanted the
ability to
On 01/15/2016 11:13 AM, 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 course).
Thus have
On 01/14/2016 06:26 PM, Jeff Law wrote:
I think the bigger question Bernd is asking here is whether or not it
makes sense to have multiple schedulers. In an ideal world we'd bake
them off select the best and deprecate/remove the others.
I didn't follow sel-sched development closely, so forgive
There are a few open PRs involving sel-sched, and I'd like to start a
discussion about removing it. Having two separate schedulers isn't a
very good idea in the first place IMO, and since ia64 is dead, sel-sched
gets practically no testing despite being the more complex one.
Thoughts?
Bernd
On 01/12/2016 06:44 AM, Jeff Law wrote:
I would argue that each of these does represent misleading
indentation and that the warning is warranted for each.
Perhaps they aren't as bad as prior cases, but I'd still
consider them mis-leading.
(https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03242.html
On 12/17/2015 02:41 AM, David Wohlferd wrote:
So how about:
- Update the basic asm docs to describe basic asm's current (and
historical) semantics (ie clobber nothing).
- Emphasize how that might be different from users' expectations or the
behavior of other compilers.
- Warn that this could ch
On 12/14/2015 09:10 AM, Segher Boessenkool wrote:
That, and adding a memory clobber degrades performance for a lot of
existing basic asm that does not expect the clobber, e.g. asm(""),
asm("#"), asm("nop"), ...
I wonder about this. People keep bringing up "a lot of existing basic
asm" in gener
(add gcc-patches)
On 12/01/2015 08:39 AM, Matthias Klose wrote:
On 01.12.2015 03:58, Ulrich Drepper wrote:
On Mon, Nov 30, 2015 at 9:14 PM, Jeff Law wrote:
Right, but isn't AC_COMPILE_IFELSE a compile test, not a run test?
The problem macro is _AC_COMPILER_EXEEXT_WORKS. The message is at
When reviewing patches I'm never quite sure which of the following we
should be using:
some_target_hook (tree decl, machine_mode mode ATTRIBUTE_UNUSED)
some_target_hook (tree decl, machine_mode ARG_UNUSED (mode))
some_target_hook (tree decl, machine_mode /* mode */)
some_target_hook (tree dec
On 10/16/2015 11:44 AM, Thomas Schwinge wrote:
Lately, Bernd has
stepped up a few times to review OMP patches (many thanks, Bernd!), but
also he sometimes stated that even though a patch appears fine to him,
he'd like "Jakub to have a look".
I'll just comment on this briefly. In general I'll tr
On 10/02/2015 05:20 PM, Thomas Schwinge wrote:
How should we handle libgfortran and libm dependencies in offloaded code?
As the linking requirements especially regarding libgfortran may be
different for each offloading target (shared and/or static libraries
supported, static linking enforced, li
On 11/21/2014 06:57 PM, Jeff Law wrote:
Bernd, please add yourself as the maintainer for that port in the
MAINTAINERS file.
Thanks, done.
Bernd
On 11/11/2014 09:30 AM, Eric Botcazou wrote:
I just don't like all the as_a/is_a stuff enforced everywhere,
it means more typing, more temporaries, more indentation.
So, as I view it, instead of the checks being done cheaply (yes, I think
the gimple checking as we have right now is very cheap) un
On 11/03/2014 10:18 AM, Jakub Jelinek wrote:
What larger merges are still planned for GCC 5?
I'm aware of pending merges from match-and-simplify branch, there
are the JIT changes partially? approved, MPX also partially? approved,
Intel offloading patches partially approved, PTX support partially
On 09/17/2014 06:39 PM, Ilya Verbin wrote:
Yeah, I got that all these prefixes are not working with modified
DESTDIR. I’ll fix mkoffload.
2014-09-17 20:30 GMT+04:00 Bernd Schmidt :
That's also a solved problem in nvptx mkoffload - you do need to unset these
environment variables when inv
eration tool for ptx
Nathan Sidwell
Bernd Schmidt
Munges PTX assembly into a C source file defining the PTX code as a
string.
This is not a complete assembler. We presume the source is well
formed from the compiler and can die horribly if it is not. */
#include "config.h"
On 09/17/2014 04:42 PM, Jakub Jelinek wrote:
mkoffload should make similar attempts to find the offloading compiler
driver. It should try (relative to mkoffload binary) probably:
../../../../../bin/x86_64-intelmic-linux-gnu-g++
(why does it try g++ and not gcc btw?), then perhaps:
./x86_64-intel
On 07/22/2014 01:24 PM, Thomas Schwinge wrote:
> On Tue, 22 Jul 2014 13:06:19 +0200, Bernd Schmidt
wrote:
>> It says "Immutable Page", so I can't seem to edit it.
>
> Probably applies for your write access to any wiki page, and that's
> because you'v
different scheme for nvptx. However, this is how it should work after I
get some patches installed. ]
For reference, I'm attaching my current version of ptx mkoffload.
Bernd
/* Offload image generation tool for ptx
Nathan Sidwell
Bernd Schmidt
Munges PTX assembly into a C sourc
On 05/23/2014 10:07 AM, shmeel gutl wrote:
Exposed pipeline is not my problem. Negative latency is my problem. I
don't see negative latency for c6x, not in unit reservations and not in
adjust cost. Did I miss something?
You just need to model it differently. Rather than saying instruction A
h
On 05/21/2014 05:30 PM, Vladimir Makarov wrote:
On 2014-05-20, 5:18 PM, shmeel gutl wrote:
The problem that I see is that the haifa scheduler schedules one cycle
at a time, in a forward order, by picking from a list of instructions
that can be scheduled without delays. So, in the above example,
On 03/27/2014 02:50 PM, Felix Yang wrote:
I find DCE in sched2 is disabled for C6X backend. Is this a
performance consideration? Or a GCC BUG?
As far as I remember, it's a problem due to how delayed instructions are
represented to the final scheduler. Just before that scheduling pass is
On 04/17/2013 11:52 PM, Steven Bosscher wrote:
> According to the comments in pa.h about MASK_JUMP_IN_DELAY, having
> jumps in delay slots of other jumps is one such thing: They don't
> bring benefit to the PA-8000 and they don't work with DWARF2 CFI. As
> far as I know, SPARC and MIPS don't allow
Count another vote for getting rid of GC.
Bernd
On 11/07/2012 12:08 PM, Paulo Matos wrote:
>
>> -Original Message-
>> From: Bernd Schmidt [mailto:ber...@codesourcery.com]
>> Sent: 07 November 2012 10:48
>> To: Paulo Matos
>> Cc: gcc@gcc.gnu.org
>> Subject: Re: Defining scheduling resource constra
On 11/07/2012 11:41 AM, Paulo Matos wrote:
> Yes, the reordering works fine. The problem is when I change the
> value of *n_readyp. The c6x port returns n_ready (which for me
> doesn't make sense since the max insns I can schedule in a cycle is 2
> which is my issue_rate), but doesn't change *n_re
On 11/06/2012 05:50 PM, Paulo Matos wrote:
> I am following your advice and using sched.reorg to remove the
> instruction from the ready list. What I am doing is checking the
> register written in ready[n_ready - 1] (if any) and look for the
> remainder of the ready list for insns writing to the s
On 11/05/2012 06:11 PM, Paulo Matos wrote:
>> -Original Message-
>> From: Bernd Schmidt [mailto:ber...@codesourcery.com]
>> Sent: 05 November 2012 16:52
>> To: Paulo Matos
>> Cc: gcc@gcc.gnu.org
>> Subject: Re: Defining scheduling resource constraint
&g
On 11/05/2012 03:51 PM, Paulo Matos wrote:
> Hello,
>
> I am experience a problem in GCC4.7 scheduler whereby the scheduler is
> issuing two instructions that write with a cond_exec to the same register. It
> ends up looking like this:
> Cond_exec p1 != 0 : r2 <- r2 and 0xf8
> Cond_exec p0 != 0:
On 04/27/2012 11:31 PM, Greg McGary wrote:
I'm working on a port that does loads& stores in two phases.
Every load/store is funneled through the intermediate registers "ld" and "st"
standing between memory and the rest of the register file.
Example:
ld=4(rB)
...
...
On 04/11/2012 06:53 PM, Peter Bigot wrote:
> On Mon, Mar 5, 2012 at 10:38 AM, Bernd Schmidt
> wrote:
>> On 03/05/2012 05:24 PM, Peter Bigot wrote:
>>> And is there any reason (other than it doesn't seem to have been done
>>> before) to believe PSImode is the
On 04/11/2012 02:57 PM, Torvald Riegel wrote:
> However, the concern you raised is only one part of the problem. The
> other is that, put in a simplified way, GCC is competing with LLVM about
> new and/or non-fulltime-compiler developers. For me, it looks like LLVM
> is more appealing to them, an
On 04/11/2012 09:45 AM, Gabriel Dos Reis wrote:
> I have been having difficulty following the twists and the turns and
> the goal post moving.
> Are you essentially requiring to see GCC rewritten in C++ before we
> switch to C++?
Frankly, despite all this discussion, we still don't really know wha
On 04/10/2012 11:39 PM, Miles Bader wrote:
> Torvald Riegel writes:
>> I hate to bring this up, but in my personal experience, getting started
>> with LLVM was _much_ easier than with GCC. LLVM is a much newer
>> codebase, so that's an advantage unrelated to the language.
>
> I dunno, I've some
On 04/04/2012 11:06 AM, Richard Guenther wrote:
> So - I'll veto the switch unless I see 1) and 2). 1) and 2) can be combined
> by transitioning vec.h to a C++ template class, with proper GC support.
> (not sure that I can veto anything - heh)
I don't think I can veto anything, but I'll go on the
On 03/30/2012 10:37 AM, Richard Guenther wrote:
> On Fri, Mar 30, 2012 at 9:14 AM, Ludovic Courtès
> wrote:
>> Hi,
>>
>> Gabriel Dos Reis skribis:
>>
>>> I do not think people working on plugins have come up with a
>>> specification and an API they agree on.
>>
>> I think it’s wrong to consider p
On 03/26/2012 07:37 PM, Eric Botcazou wrote:
>> Does 4.7 still have the failure at all? I've checked with the 4.6
>> branch, and regrename gets confused because there's a REG_DEAD note for
>> the register, and another REG_UNUSED for the same reg. As far as I
>> remember, it used to be the case that
On 03/13/2012 12:41 AM, Andreas Schwab wrote:
> Andreas Schwab writes:
>
>> Ian Lance Taylor writes:
>>
>>> Andreas Schwab writes:
>>>
Ian Lance Taylor writes:
> But it also looks like the pattern should use a match_scratch.
It is also used as input in operand 2.
>>>
>>
On 03/09/2012 04:20 PM, Aurelien Buhrig wrote:
> I'm not used to work at tree level for now and it is unclear for me what
> part of the code should be tweaked. Can you tell me which part of the
> code you are fixing/looking at, so that I can have a better
> understanding of ptr_mode vs Pmode before
On 03/09/2012 11:20 AM, Aurelien Buhrig wrote:
> Hi,
>
> It seems there is an issue around subreg:HI of PSI hardware register,
> which occurs either during expand or reload (GCC 4.6.1).
>
> For my big endian target,
> (subreg:HI (reg:PSI A0_REGNO) 0) is not representable but
> (subreg:HI (reg:PSI
On 03/05/2012 05:24 PM, Peter Bigot wrote:
> And is there any reason (other than it doesn't seem to have been done
> before) to believe PSImode is the wrong way to support a
> general-purpose 20-bit integral type in gcc?
If you're using 4.7.0, it should be possible to use FRACTIONAL_INT_MODE
and g
On 02/22/2012 05:15 PM, Henderson, Stuart wrote:
>> Make an exception for BImode and small_register_classes_for_mode_p
>> (BImode).
>
> Thanks Bernd.
>
> Would this be acceptable:
>
> diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
> index 8d81c89..e4e13ab 100644
> --- a/gcc/ifcvt.c
> +++ b/gcc/ifcvt.c
>
On 02/22/2012 01:23 PM, Henderson, Stuart wrote:
> The problem with noce_get_condition is that if the condition variable
> is a MODE_INT register it will return it and set earliest as the jump
> insn itself. I'm not sure why this is the case, but it seems like
> something we don't want to be doing
On 02/14/2012 07:12 PM, Henderson, Stuart wrote:
>> spill_failure does return for asms since we don't want to ICE on bad
>> user code. That's all that's going on here.
>
> ahh, thanks.
>
>> It sounds like ifcvt needs to be fixed. Your example:
>>> block 44:
>>> set cc = x;
>>> set cc = y; (*)
>>>
On 02/07/2012 07:42 PM, Henderson, Stuart wrote:
> Hi,
> I'm investigating the following ICE building the Blackfin compiler from trunk:
> /home/shender/gnu-upstream/toolchain/gcc-4.7/libgfortran/generated/eoshift1_4.c:
> In function ÃâËeoshift1Ãââ:
> /home/shender/gnu-upstream/toolchain/gcc-4.7/li
On 12/28/2011 07:13 PM, Michael Eager wrote:
> Hi --
>
> I've run into a problem with the MicroBlaze backend
> where it is not recognizing a return pattern. I'm
> trying to modify the back end to use the 'simple_return'
> pattern, rather than 'return', since MicroBlaze has
> exactly what the docu
On 11/04/11 15:37, Hans-Peter Nilsson wrote:
> On Thu, 3 Nov 2011, Iyer, Balaji V wrote:
>> Is it possible to make sure that the "LABELX" occurs right
>> after the "Call some_function" instruction (and the instruction
>> scheduler moves the label with the call INSN)? I insert the
>> label right aft
On 10/07/11 09:50, BELBACHIR Selim wrote:
> (asm result)
>
> load d($C2),$R1 <--1st operand for comparison ctrl,readmem,nothing
> loadi 0,$C4 <- 2nd operand for comparison ctrl,nothing
> load d($C2+4),$R2 <--no data dependancies ctrl,readmem,nothing
> cmp $C4,$R1
On 09/29/11 17:36, Jeff Law wrote:
> On 09/29/11 09:26, Bernd Schmidt wrote:
>> ISTR cse.c has some support for this.
> cprop.c -- see references to implicit_sets.
cse too: record_jump_equiv.
Bernd
On 09/29/11 16:43, Rahul Kharche wrote:
>
>> insn 882 : cc <- compare (r684, 0)
>> jump_insn 883 : if (cc != 0) goto insn 46
>> insn 49: r291 <- r684
>> ..
>> insn 46
>>
>> cc contains the result of subtracting 0 from r684; control flow goes to
>> insn_49 only if (cc == 0)
On 09/22/11 16:40, Alan Modra wrote:
> The bootstrap breakage happens on libmudflap/mf-hooks1.c, compiling
> __wrap_malloc. Eliding some detail, this function starts off as
>
> void *__wrap_malloc (size_t c)
> {
> if (__mf_starting_p)
> return __real_malloc (c);
>
> The "if" is bb2, the si
g patch.
Bernd
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 177967)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2011-08-22 Bernd Schmidt
+
+ * config/c6x/c6x.md (indirect_jump_shadow): Tweak represent
On 07/19/11 23:33, Richard Henderson wrote:
> But after pass_partition_blocks, we run into trouble. There
> are no less than 4 other passes that add *new* crossing jumps
> without doing *any* of the subsequent fixups for less capable
> targets: pass_outof_cfg_layout_mode, pass_reorder_blocks,
> pa
On 07/12/11 13:11, Georg-Johann Lay wrote:
> Not familiar with combine inerts, I'd like to know if
> it's low hanging fruit to teach insn combine to perform
> optimizations like the following.
>
> Suppose following C code, int = HI
>
> int y15;
> int x15;
>
> void qmul8_xy (char c, int x, int y)
On 07/11/11 18:42, Bernd Schmidt wrote:
> On 07/11/11 18:12, Georg-Johann Lay wrote:
>> The reason is that IRA (or reload, don't see it from the dumps)
>> combines the insns again to:
>>
>> (insn 29 31 24 2 (parallel [
>> (set (reg:HI 24 r24 [49])
On 07/11/11 18:12, Georg-Johann Lay wrote:
> The reason is that IRA (or reload, don't see it from the dumps)
> combines the insns again to:
>
> (insn 29 31 24 2 (parallel [
> (set (reg:HI 24 r24 [49])
> (mult:HI (reg:HI 18 r18)
> (const_int 15 [0xf])
On 07/11/11 13:27, Georg-Johann Lay wrote:
>>> IRA now propagates insn 7 into insn 8 so that in insn-output gcc runs
>>> into the gcc_unreachable() even though !reload_in_progress etc should
>>> keep IRA/reload from generating the insn.
That can't work because reload_in_progress isn't set during I
I think it's great that Richard was appointed. I also understand Vlad's
frustration and can't imagine why he isn't RA maintainer.
On 06/28/11 14:39, Richard Guenther wrote:
> We discussed the maintainer appointing process at the London GCC
> Gathering event, a summary can be looked up at the pdf a
On 06/01/2011 06:06 PM, Georg-Johann Lay wrote:
> From the internals description, HARD_FRAME_POINTER_REGNUM appears to
> serve different purpose, and sources indicate that it is used similar,
> i.e. per regno == HARD_FRAME_POINTER_REGNUM instead if having a rtx or
> reg_class and test for overlaps
On 06/01/2011 05:35 PM, Georg-Johann Lay wrote:
> The reason for why a subreg of hardreg is there during reload is that
> on avr, r29:r28 is the frame pointer (word_mode is QI and Pmode is
> HI). Because in many places of the compiler, there are tests like "if
> (regno == FRAME_POINTER_REGNUM)", t
On 06/01/2011 04:00 PM, Georg-Johann Lay wrote:
> Eric Botcazou schrieb:
>>> You are right, I was staring at the wrong place. subreg of hardreg
>>> should not be there.
>>
>> You can take a look at PR target/48830, this is a related problem for the
>> SPARC where reload generates:
>>
>> (set (reg:
ru
avr port Eric Weddington eric.wedding...@atmel.com
bfin port Bernd Schmidt ber...@codesourcery.com
bfin port Jie Zhang jzhang...@gmail.com
+c6x port Bernd Schmidt ber...@codesourcery.co
On 05/05/2011 11:53 PM, Ian Lance Taylor wrote:
> Jon Grant writes:
>
>> Is it expected that more than one -o option should be allowed by GCC
>> on command line? The later -o option overriding earlier.
>
> Yes, this is expected. Most Unix utilities behave that way: when an
> option with an argu
On 04/05/2011 04:49 PM, Jeff Law wrote:
> On 04/04/11 20:57, H.J. Lu wrote:
>> Patch was checked in at Fri Apr 1 17:46:17 2011. I reported the failure
>> at 2011-04-01 18:49:28 and identified the range of causes. It is too bad
>> to take 3 days to fix it.
> Note the checking was Friday evening,
On 04/05/2011 02:23 PM, Steven Bosscher wrote:
> However, my point is that developers can investigate breakage without
> keeping the trunk broken.
If they can reproduce it; you don't always have access to the system
that shows the breakage. A reversion policy that's too trigger-happy can
leave yo
On 04/05/2011 08:26 AM, Steven Bosscher wrote:
> I don't understand, really, why it's such a big deal to revert a patch
> quickly if it broke something.
To answer this as well, firstly a proposal that comes with a request to
revert the wrong patch discredits itself.
Breaking stuff by accident is
On 04/05/2011 08:26 AM, Steven Bosscher wrote:
> On Tue, Apr 5, 2011 at 3:14 AM, Bernd Schmidt wrote:
>
>> For i686-linux bootstraps it's hard to argue against it, but in general
>> I find it easier to cope with the occasional broken tree than with
>> getting pa
On 04/05/2011 12:51 AM, Ian Lance Taylor wrote:
> Steven Bosscher writes:
>
>> My proposal would be: A patch may be reverted immediately by anyone
>> with SVN write access if bootstrap is broken for more than 24 hours on
>> any primary target. With proper notification to everyone involved,
>> obv
On 04/04/2011 11:58 PM, Steven Bosscher wrote:
> In the PR audit trail, I've proposed to revert the patch, and HJ and
> Benjamin are also in favor of that. In Benjamin's works: Bootstrap has
> been broken for much too long, on all the common devel arches.
Which is not actually true, see the secon
On 02/11/2011 07:43 PM, Frédéric RISS wrote:
> Le vendredi 11 février 2011 à 13:33 +0100, Bernd Schmidt a écrit :
>> Suppose I have two insns, one reserving (A|B|C), and the other reserving
>> A. I'm observing that when the first one is scheduled in an otherwise
>> empt
On 02/11/2011 02:13 PM, Alexander Monakov wrote:
> Could you please clarify a bit: would the modified behavior match what your
> target CPU does? The current behavior matches CPUs without lookahead in
> instruction dispatch: the first insn goes to the first matching execution
> unit (A), the secon
Suppose I have two insns, one reserving (A|B|C), and the other reserving
A. I'm observing that when the first one is scheduled in an otherwise
empty state, it reserves the A unit and blocks the second one from being
scheduled in the same cycle. This is a problem when there's an
anti-dependence of c
On 08/24/2010 07:38 PM, Basile Starynkevitch wrote:
> * what is the preferred way of obtaining a sequence of small patches?
> svn diff -x -p gives one big *.diff file! Should we split it by hand?
> Are there other tools producing a sequence of small patches?
http://savannah.nongnu.org/projects/qui
On 08/23/2010 08:05 PM, Mohamed Shafi wrote:
> sub.s32 srcdstGP, #imm16 // signed 16-bit register to immediate subtract
> sub.u32 srcdstGP, #imm16 // unsigned 16-bit register to immediate subtract
If you're using a bit to decide between these two, a better encoding
would be to just support a sing
On 08/20/2010 10:51 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> Sometime I have to do
>>
>> int x = 0;
>>
>> to silence gcc from uninitialized warnings when I know it is
>> unnecessary. Is that a good idea to add
>>
>> int x __attribute__ ((uninitialized));
>>
>> to tell compiler that i
On 08/08/2010 05:08 PM, Uros Bizjak wrote:
> So, you will be able to use --enable-frame-pointer configure option.
Or, presumably the -fno-omit-frame-pointer command line option?
Bernd
1 - 100 of 215 matches
Mail list logo
