Paul Eggert wrote:
That's great, but GCC has had many other hands stirring the pot.
I daresay a careful scan would come up with many other examples of
undefined behavior due to signed integer overflow. (No doubt
you'll be appalled by them as well, but there they are.)
That's handwaving, not ev
Paul Eggert wrote:
(2) In the current SPEC, how many programs benefit from undefined overflow
semantics and how much does each benefit?
Those questions are more for the opponents of -fwrapv, so
I'll let them answer them. But why are they relevant?
It's relevant in a "did my system just becom
Paul Eggert wrote:
"Richard Guenther" <[EMAIL PROTECTED]> writes:
Authors of the affected programs should adjust their makefiles
That is what the proposed patch is for. It gives a way for
developers to adjust their makefiles.
A developer of portable software cannot simply put something
like
Eric Blake wrote:
/* The maximum and minimum values for the integer type T. These
macros have undefined behavior if T is signed and has padding bits.
If this is a problem for you, please let us know how to fix it for
your host. */
#define TYPE_MINIMUM(t) \
((t) (! TYPE_SIGNED (t) \
Paul Eggert wrote:
But so far, benchmark scores are the only scores given by the people
who oppose having -O2 imply -fwrapv.
And you expect real-world results will be different because...?
You say you doubt it affects performance. Based on what? Facts
please, not guesses and hand-waiving...
Richard Sandiford wrote:
I know Andrew replied privately, but I hope he doesn't mind me raising
the issue on-list. I just wanted to guage the general feeling as to
whether I'd screwed up, and whether I should have submitted the patches
in a different way.
I wish everyone did things this thorou
While running the testsuite (for the first time in a few weeks), xgcc no
longer seems to find the libc include files in /prefix for a bfin-elf
target. It appears that while building libraries, we're careful to pass
"-isystem /opt/uClinux/bfin-elf/bfin-elf/include -isystem
/opt/uClinux/bfin-elf
I've been converting the Blackfin port to take advantage of the new
lower-subreg pass, which fortunately involves little more than deleting
a few patterns.
One problem is that without an anddi3 expander, we generate poor initial
RTL. optabs knows it can do the operation piecewise, so it could
Vladimir N. Makarov wrote:
And I am disagree that it is within compilation time guidelines set
by SC. Ken fixed a big compilation time degradation a few days ago
and preliminary what I see now (comparison with the last merge point)
is
x86_64
SPECInt2000 5.7%
SPECFp200 8.7%
ppc64
SPECInt200
Zack Weinberg wrote:
I have worked out a tentative plan for replacing most of these macros
with ordinary target hooks, and eliminating REG_OK_STRICT. I propose
to change GO_IF_LEGITIMATE_ADDRESS, GO_IF_MODE_DEPENDENT_ADDRESS,
LEGITIMIZE_ADDRESS, LEGITIMIZE_RELOAD_ADDRESS, REG_OK_FOR_BASE_P,
REG_MO
Miles Bader wrote:
Say I've got a mov instruction that only works via an accumulator A, and
a two-operand add instruction. "r" regclass includes regs A,X,Y, and
"a" regclass only includes reg A.
So mov has constraints like: 0 = "g,a" 1 = "a,gi"
and add3 has constraints: 0 = "r" 1 = "0"
Jeffrey A Law wrote:
On Fri, 2005-01-21 at 17:50 +0100, Giovanni Bajo wrote:
Why not putting it on a branch? If you are going to finish and submit it for
4.1, it might be easier to use CVS.
It might also be easier for those of us who want to play with the code,
without having to find a suitable syn
Giovanni Bajo wrote:
What is your plan for this branch? Is there more code refactoring/rewriting
planned, or are you just going to give it a wider testing and fix fallout bugs,
in preparation for a merge?
There's one known design flaw wrt. to enble_optional/disable_optional,
and I think autoinc re
I'm updating the copyrights in the Blackfin port, and I noticed that
there appear to be two versions of the wording that allows more-or-less
unlimited use of libgcc files. One can be found e.g. in
config/arm/crtn.asm:
As a special exception, if you link this library with files
compiled wit
Ulrich Weigand wrote:
- As mentioned in http://gcc.gnu.org/ml/gcc/2005-01/msg00911.html
there is a code path in find_reloads that sets rld[].inc to a
nonzero value even for a platform that doesn't actually *have*
pre-/post-increment insns, leading to an ICE later on.
The patch below simply
(slowly catching up with vacation backlog)
James E Wilson wrote:
Reload is using registers without setting regs_ever_live. The IA-64
prologue code needs a temp register to save/restore b0, and it uses
regs_ever_live to find one. Also, because we have variable size
register windows, we need the
Steven Bosscher wrote:
On Friday 08 April 2005 00:12, James E Wilson wrote:
On Thu, 2005-04-07 at 04:35, Bernd Schmidt wrote:
Try the patch below - does it fix the problem?
OK, I will try it. This may take about 2 days. My lone IA-64 machine
is busy doing other stuff at the moment.
With this
Ulrich Weigand wrote:
- As mentioned in http://gcc.gnu.org/ml/gcc/2005-01/msg00911.html
there is a code path in find_reloads that sets rld[].inc to a
nonzero value even for a platform that doesn't actually *have*
pre-/post-increment insns, leading to an ICE later on.
Index: gcc/reload.c
I guess the best solution is to change the place you modified, but to
use a test that checks for autoinc codes. I'll come up with something.
Try this.
Bernd
* reload.c (find_reloads): Only set INC field if we know we have an
autoinc reload.
* reload.h (struct reload): Update comment to match.
Zack Weinberg wrote:
The target macros described in the "Addressing Modes" section of the
internals manual are rather badly in need of cleaning up.
What's your status on this - would you mind very much if I made changes
to those macros now?
Bernd
Paul Schlie wrote:
From: Robert Dewar <[EMAIL PROTECTED]>
You keep saying this over and over, but it does not make it true. Once
again, the whole idea of making certain constructs undefined, is to
ensure that efficient code can be generated for well defined constructs.
- Can you give an exampl
Jeffrey A Law wrote:
I'd tend to agree. I'd rather see the option go away than linger on
if the option is no longer useful.
I wouldn't mind that, but I'd also like to point out that there are
Makefiles out there which hard-code things like -fforce-mem. Do we want
to keep the option as a stu
Steven Bosscher wrote:
I guess that, apart from the legal discussion of whether this enough,
such a statement would not apply to existing content. It was certainly
not my intention to sign over the various Wiki contributions I have
made to the FSF.
This strikes me as shortsighted. If we're ge
Kurt Wall wrote:
On Mon, Jul 11, 2005 at 04:27:58PM -0400, Daniel Berlin took 34 lines to write:
On Mon, 2005-07-11 at 13:09 -0700, Robert Thorpe wrote:
Also, a web-browser is much slower than an info-browser, especially
when doing searchs.
You must be close to the only user i've met who us
Andreas Krebbel wrote:
Ok I understand that implementing the special lifeness analyzers in global alloc
using the df.c framework would ease reusing it somewhere else. But my question
was more basic.
So do you agree that using one lifeness analyzer for checking what
an optimizer step has done bas
Daniel Berlin wrote:
If you make them all defined, then it's going to be live where it wasn't
before, even though it's not really *used* over those paths.
The idea is to put the initialization insns only on the paths where the
register will be uninitialized.
Bernd
Steven Bosscher wrote:
On Tuesday 23 August 2005 17:06, Bernd Schmidt wrote:
The idea is to put the initialization insns only on the paths where the
register will be uninitialized.
int foo (int n)
{
int a;
while (--n)
a = n;
return a;
}
Not knowing n, how can you be sure
Daniel Jacobowitz wrote:
Hey Bernd,
Has there been any news or progress on reload-branch lately? It
removes a lot of code that I'd dearly love to see gone...
Unfortunately not. I just don't have the time to work on too many extra
projects at the moment :-( Of course, others could always vo
Joe Buck wrote:
Are there any maintainers (folks in MAINTAINERS) who have objections or
concerns?
I haven't played with svn much, but from what I hear about the
advantages I'm all for it. cvs is so 20th century.
Bernd
Lars Gullik Bjønnes wrote:
It seems that svn is unable to send all its requests to the svn
repo over one ssh connection. In one test I just did I had to enter
the ssh password five times.
man ssh-agent
Bernd
David Daney wrote:
Perhaps not in general, but one unstated premise of this whole thread is
that for some GCC targets (most Unix like operating systems) you *can*
count on a SIGSEGV when you dereference a null pointer. The java front
end takes advantage of this fact to eliminate explicit check
Andrew Haley wrote:
Bernd Schmidt writes:
> David Daney wrote:
> > Perhaps not in general, but one unstated premise of this whole thread is
> > that for some GCC targets (most Unix like operating systems) you *can*
> > count on a SIGSEGV when you dereference a null poi
Daniel Jacobowitz wrote:
On Thu, Nov 17, 2005 at 03:42:29PM -0800, Ian Lance Taylor wrote:
I just tried a simple unoptimized compile. -ftime-report said that
final took 5% of the time (obviously final does more than formatting),
and the assembler took 4% of the total user time, and system time
Andrew Haley wrote:
Bernd Schmidt writes:
> Hmm, we can trap null pointer accesses, but I don't think we deliver
> reliable SIGSEGV signals yet or provide a means of getting the faulting
> address. If that was fixed, is there anything obvious that stands in
> the
Giovanni Bajo wrote:
Bernd,
I read you're interested in code-size optimizations. I'd like to point you
to this patch:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00554.html
which was never finished nor committed (I don't know if RTH has a newer
version though). This is would be of great help f
Daniel Berlin wrote:
On Thu, 2005-12-15 at 00:48 +0100, Steven Bosscher wrote:
Hi,
Someone caused a >10% compile time regression yesterday for CSiBE, see
http://www.csibe.org/draw-diag.php?branchid=mainline&flags=-Os&rel_flag=--none--&dataview=Timeline&finish_button=Finish&draw=sbs&view=1&base
Diego Novillo wrote:
On Tuesday 03 January 2006 12:17, [EMAIL PROTECTED] wrote:
how to keep my branch updated with the mainline?
The easiest way is using svnmerge.py (included in SVN's contrib directory).
There's documentation in the GCC wiki: http://gcc.gnu.org/wiki/SvnBranch
Just tried
This was the correct command to do, assuming that you *never* merged your
branch since its original creation. I inspected the history of the branch
(through 'svn log') and it seems this assumption is correct.
Yes.
Anyway, I have fixed the bug in svnmerge and attached a new version for you
in t
One additional question, suppose I don't want to merge a huge number of
revisions in one go, and I do
svnmerge.py merge -r a-small-list-of-revisions
svn diff ;; to verify everything is OK
Do I then have to commit the merge so far before running svnmerge.py
again, or can it get all the infor
Giovanni Bajo wrote:
Bernd Schmidt <[EMAIL PROTECTED]> wrote:
One additional question, suppose I don't want to merge a huge number of
revisions in one go, and I do
svnmerge.py merge -r a-small-list-of-revisions
svn diff ;; to verify everything is OK
Do I then have to commit t
One more question (I'm experimenting... excuse the stupid questions but
I'd rather not accidentally mess up the branch). What I did now was, first,
~/svnmerge.py merge -r 96659-96679
just to get started, then
~/svnmerge.py merge -F -r 96681,,9
with the list of numbers cut&pasted fro
Daniel Berlin wrote:
On Wed, 11 Jan 2006, Bernd Schmidt wrote:
The merge script relies only on the svnmerge-integrated property, not
on the commit messages?
Right.
It's just trying to generate a nice message for you, but in our world,
the messages are so huge as to be useless.
I
Daniel Berlin wrote:
mysql> delete from longdescs where length(thetext) > 100;
Query OK, 251 rows affected (2 min 12.11 sec)
Thank you.
I may just set up a pre-commit hook to check the log message length and
hav eit not let you commit if it's ridiculously large.
Maybe checkins on a bran
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 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 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 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
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
(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
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
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 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
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/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
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/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/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/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/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 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 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/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 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 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 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/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 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 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
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 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
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
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 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
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 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/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 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 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/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/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 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 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 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 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 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 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/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 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-
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 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
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 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 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/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 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 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 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 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
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 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:
1 - 100 of 215 matches
Mail list logo
