> On Oct 31, 2018, at 3:55 PM, Segher Boessenkool
> wrote:
>
> On Wed, Oct 31, 2018 at 02:20:38PM -0400, Paul Koning wrote:
>> I see some test cases that say dg-add-options ieee. That apparently means:
>> pretend we have IEEE float even when the target does not.
&
I see some test cases that say dg-add-options ieee. That apparently means:
pretend we have IEEE float even when the target does not.
What is the point of doing that? On non-IEEE targets such test cases fail --
at least they do on pdp11. Instead I'd expect a check that skips these tests
if no
I noticed a curious inconsistency.
Some testcases (like gcc.dg/Wrestrict-4.c) have declarations like this:
void *alloca();
void* memcpy ();
Those don't generate warnings in a just built V9.0 gcc for x86. And the
testcase clearly doesn't expect warnings.
But I do get a warning (warning: confli
> On Oct 29, 2018, at 4:08 PM, Martin Sebor wrote:
>
> On 10/29/2018 09:19 AM, Paul Koning wrote:
>>
>>
>>> On Oct 29, 2018, at 10:54 AM, Martin Sebor wrote:
>>>
>>> On 10/29/2018 07:45 AM, Paul Koning wrote:
>>>> I noticed an i
> On Oct 29, 2018, at 11:18 AM, Paul Koning wrote:
>
> ...
>
>> That said, attribute problems aren't handled perfectly consistently
>> in GCC. Some result in errors, others in warnings, and some are
>> silently ignored. I've been tracking the prob
> On Oct 29, 2018, at 10:54 AM, Martin Sebor wrote:
>
> On 10/29/2018 07:45 AM, Paul Koning wrote:
>> I noticed an inconsistency in the handling of the aligned attribute. When
>> applied to variables, I get an error message if the alignment is too large
>>
> On Oct 29, 2018, at 10:54 AM, Martin Sebor wrote:
>
> On 10/29/2018 07:45 AM, Paul Koning wrote:
>> I noticed an inconsistency in the handling of the aligned attribute. When
>> applied to variables, I get an error message if the alignment is too large
>>
I noticed an inconsistency in the handling of the aligned attribute. When
applied to variables, I get an error message if the alignment is too large for
the platform. But when applied to functions, there is no error check. The
same applies to label alignment (from the -falign-labels switch).
I was reviewing some back end code that handles integer values of various
sizes, and got confused reading about CONST_INT and CONST_DOUBLE.
It's pretty clear that CONST_DOUBLE is used for values bigger than
HOST_WIDE_INT. But the description of INTVAL is contradictory. In some
places, it stat
In my target (pdp11) which has 16 bit words, I see some test suite failures
because of unresolved references to __cmpsi2. The strange thing is that most
of the time 32 bit compares are expanded by GCC into a sequence of word
compares and branches.
Why would GCC sometimes generate library calls
> On Oct 23, 2018, at 6:08 AM, Richard Biener
> wrote:
>
> On Tue, Oct 23, 2018 at 2:39 AM Paul Koning wrote:
>>
>> In running the gcc testsuite on pdp11, I get some failures like this:
>>
>> collect2: fatal error: /Users/pkoning/Documents/svn/buildp
In running the gcc testsuite on pdp11, I get some failures like this:
collect2: fatal error: /Users/pkoning/Documents/svn/buildpdp/gcc/nm returned 1
exit status
compilation terminated.
compiler exited with status 1
FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O3
-fomit-frame-
> On Oct 11, 2018, at 3:11 AM, Segher Boessenkool
> wrote:
>
> Hi!
>
> On Wed, Oct 10, 2018 at 08:55:12PM -0400, Paul Koning wrote:
>
> [ snip ]
>
>> ...
>> Why is this happening, and how can I fix it (short of removing the
>> doloop_end patt
I have a doloop_end pattern in pdp11.md which looks like this:
(define_insn_and_split "doloop_end"
[(set (pc)
(if_then_else
(ne (match_operand:HI 0 "nonimmediate_operand" "+r,!m")
(const_int 1))
(label_ref (match_operand 1 "" ""))
(pc)))
(set (m
> On Jul 17, 2018, at 9:36 AM, Richard Biener
> wrote:
>
> On Tue, Jul 17, 2018 at 3:08 PM Paul Koning wrote:
>>
>>
>>> On Jul 17, 2018, at 5:46 AM, Richard Biener
>>> wrote:
>>>
>>>> ...
>>>
>>> There i
I'm trying to build the current code on Linux with GCC 4.3.2 (stock compiler in
Fedora 10 which is my old test system). It fails like this:
In file included from
/mnt/hgfs/pkoning/Documents/svn/gcc/gcc/tree-data-ref.h:27,
from
/mnt/hgfs/pkoning/Documents/svn/gcc/gcc/gimple-loo
> On Oct 8, 2018, at 5:43 PM, Eric Botcazou wrote:
>
>> That's correct, I was explaining from the middle-end perspective. There
>> we are consciously more lenient as we have to support the real world and
>> other languages than C. This is one of the cases.
>
> This had worked as Paul expect
> On Oct 8, 2018, at 1:29 PM, Andrew Haley wrote:
>
> On 10/08/2018 06:20 PM, Michael Matz wrote:
>> Only if you somewhere visibly add accesses to *i and *j. Without them you
>> only have the "accesses" via memcpy, and as Richi says, those don't imply
>> any alignment requirements. The i a
> On Oct 8, 2018, at 11:09 AM, Richard Biener
> wrote:
>
> On Mon, Oct 8, 2018 at 3:57 PM Paul Koning wrote:
>>
>> I have a movmem pattern in my target that pays attention to the alignment
>> argument.
>>
>> GCC isn't passing in the ex
I have a movmem pattern in my target that pays attention to the alignment
argument.
GCC isn't passing in the expected alignment part of the time. I have this test
case:
extern int *i, *j;
extern int iv[40], jv[40];
void f1(void)
{
__builtin_memcpy (i, j, 32);
}
void f2(void)
{
__buil
> On Oct 5, 2018, at 12:21 PM, Richard Biener
> wrote:
>
> On October 5, 2018 4:17:53 PM GMT+02:00, Paul Koning
> wrote:
>> The documentation says that argument 4 of the blkmov insn gives the
>> alignment, for example 4 if things are word-aligned.
>>
The documentation says that argument 4 of the blkmov insn gives the alignment,
for example 4 if things are word-aligned.
It's documented that, say, the value 4 means source and destination are
multiples of 4. What isn't clear is whether the length is also a multiple of 4
in this case. In othe
that correct? It seems that this is worth using for any machine where it's
desirable to avoid executing stack data.
paul
> On Aug 31, 2018, at 9:19 AM, Paul Koning wrote:
>
>
>
>> On Aug 30, 2018, at 9:02 PM, Jeff Law wrote:
>>
>> On 08/30/2018 10:5
> On Sep 4, 2018, at 12:40 PM, gérard Calliet
> wrote:
>
> (our build version is 4.7.3)
>
> Hello,
>
> I'm just a beginner in gcc. (I contributed to the rebuild of the gnat ada
> compiler (version 3.4.7) on OpenVMS last year:
> https://github.com/AdaLabs/gnat-vms).
>
> As I do love books
> On Sep 3, 2018, at 1:25 PM, Matthew Malcomson
> wrote:
>
>>>
>>> Thanks for the suggestions,
>>> I've had a look into these, and unfortunately it seems they have the same
>>> problem I've been hitting before.
>>>
>>> The use of the TARGET_HARD_REGNO_MODE_OK macro limits all uses of regis
> On Sep 3, 2018, at 12:10 PM, Matthew Malcomson
> wrote:
>
>>
>> I think you can use pdp11 as an example, it does two things that are similar
>> to what you're describing.
>>
>> One is that it requires SImode to go into an even regno, and indicates that
>> it uses two registers. See TAR
> On Aug 31, 2018, at 11:41 AM, Matthew Malcomson
> wrote:
>
> Hi there,
>
> 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.
>
> The problem is the one mentioned explicitl
> On Aug 20, 2018, at 7:17 AM, Segher Boessenkool
> wrote:
>
> On Tue, Aug 14, 2018 at 03:32:01PM -0400, Paul Koning wrote:
>> I'm trying to convert the pdp11 target to use LRA.
>>
>> A lot of it "just works". But one of the test suite files
> On Aug 20, 2018, at 7:17 AM, Segher Boessenkool
> wrote:
>
> On Tue, Aug 14, 2018 at 03:32:01PM -0400, Paul Koning wrote:
>> I'm trying to convert the pdp11 target to use LRA.
>>
>> A lot of it "just works". But one of the test suite files
> On Aug 15, 2018, at 1:01 AM, Jeff Law wrote:
>
> On 08/14/2018 01:32 PM, Paul Koning wrote:
>> I'm trying to convert the pdp11 target to use LRA.
>>
>> A lot of it "just works". But one of the test suite files fails in a way
>> that I can&#
I'm trying to convert the pdp11 target to use LRA.
A lot of it "just works". But one of the test suite files fails in a way that
I can't figure out at all. I'm hoping for some help or hints to track down the
cause and come up with a fix.
The failing program is testsuite/gcc.c-torture/compile/
> On Jul 23, 2018, at 12:21 PM, Jeff Law wrote:
>
>>
> Hell, I'd live with doing a "reasonable effort" for the vast majority of
> our branches. Other than the trunk, active release branches and a few
> active development branches I don't think we really care about 'em.
>
> jeff
There are t
> On Jul 23, 2018, at 10:21 AM, Joseph Myers wrote:
>
> On Tue, 17 Jul 2018, Paul Koning wrote:
>
>> That reveals some things but nothing jumps out at me. However... pdp11
>> is an a.out target, not an ELF target. Would that explain the problem?
>> If yes
> On Jul 20, 2018, at 12:37 PM, Segher Boessenkool
> wrote:
>
> On Fri, Jul 20, 2018 at 11:49:05AM +0200, Martin Liška wrote:
>> Fully agree with that. Coming up with a new scripts written in python2 really
>> makes no sense.
>
> Then python cannot be a build requirement for GCC, since some
> On Jul 19, 2018, at 4:49 AM, U.Mutlu wrote:
>
> Hi,
> it makes me 'crazy' when I see such if-else constructs:
> if (x)
>return 7;
> else
>return 4;
>
> (Of course in this case one better would use the shorthand "return x ? 7 :
> 4;", but that's not the issue here)
>
> The 'else'
> On Jul 18, 2018, at 1:22 PM, Boris Kolpackov wrote:
>
> Paul Koning writes:
>
>>> On Jul 18, 2018, at 11:13 AM, Boris Kolpackov
>>> wrote:
>>>
>>> I wonder what will be the expected way to obtain a suitable version of
>>> Python
> On Jul 18, 2018, at 11:13 AM, Boris Kolpackov wrote:
>
> On Tue, 2018-07-17 at 14:49 +0200, Martin Liška wrote:
>
>> My question is simple: can we starting using a scripting language like
>> Python and replace usage of the AWK scripts?
>
> I wonder what will be the expected way to obtain a
> On Jul 17, 2018, at 8:23 PM, David Malcolm wrote:
>
>>> Hi.
>>>
>>> I've recently touched AWK option generate machinery and it's quite
>>> unpleasant to make any adjustments. My question is simple: can we
>>> starting using a scripting language like Python and replace usage
>>> of
>>> the A
> On Jul 17, 2018, at 9:38 AM, Richard Biener
> wrote:
>
>> ...
>> lldb? eh ... ;)
Yes, gdb is hard to make work on Mac OS.
>> anyhow, this is
>>
>> namespace std
>> {
>>
>> # 56
>> "/Users/pkoning/Documents/svn/buildpdp/pdp11-aout/libstdc++-v3/include/type_traits"
>> 3
>> template
>>
> On Jul 13, 2018, at 3:12 PM, U.Mutlu wrote:
>
> Paul Koning wrote on 07/13/2018 08:56 PM:
>>
>>
>>> On Jul 13, 2018, at 2:52 PM, U.Mutlu wrote:
>>>
>>> Paul Koning wrote on 07/13/2018 08:27 PM:
>>>> I'm trying to see if I
> On Jul 13, 2018, at 2:52 PM, U.Mutlu wrote:
>
> Paul Koning wrote on 07/13/2018 08:27 PM:
>> I'm trying to see if I can build the pdp11 target for languages other than
>> just C, and the answer is for the most part yes. But I' running into an ICE
>>
I'm trying to see if I can build the pdp11 target for languages other than just
C, and the answer is for the most part yes. But I' running into an ICE I can't
figure out. It's way before the back end comes into the picture as far as I
can see, and there's nothing particularly strange looking i
> On Jul 13, 2018, at 9:36 AM, Janus Weil wrote:
>
> Hi Paul,
>
> Fortran problems are best discussed on fort...@gcc.gnu.org
> <mailto:fort...@gcc.gnu.org> (in CC) ...
>
> 2018-07-12 21:22 GMT+02:00 Paul Koning <mailto:paulkon...@comcast.net>>:
>
I tried to rebuild for target pdp11 with fortran enabled (in the past I've just
enabled C). It builds fine but the resulting compiler crashes at startup:
Paul-Konings-MacBook-Pro:gcc pkoning$ ./xgcc -B. -O2 -S ../../hello.f
f951: internal compiler error: gfc_validate_kind(): Got bad kind
libback
> On Jul 10, 2018, at 2:18 PM, NightStrike wrote:
>
> On Fri, Jul 6, 2018 at 1:17 AM, Siddhesh Poyarekar
> wrote:
>> ...
>>
>> We had discussed making addition of ChangeLog entries into the commit
>> message mandatory but the issue there is that commit logs cannot be (or more
>> precisely,
> On Jul 6, 2018, at 6:18 AM, Bernd Edlinger wrote:
>
> You can get much better code if you make xrci a bit field.
> so the entire bit filed region can be accessed word-wise:
>
>
> #include
>
> struct Xrb
> {
>uint16_t xrlen; /* Length of I/O buffer in bytes */
>uint16_
> On Jul 5, 2018, at 9:01 PM, Paul Koning wrote:
>
>
>
>> On Jul 5, 2018, at 6:47 PM, Eric Botcazou wrote:
>>
>>> So back to the previous one: anything I can do about a 24 bit field getting
>>> split into three movqi rather than a movqi plus a mov
> On Jul 5, 2018, at 6:47 PM, Eric Botcazou wrote:
>
>> So back to the previous one: anything I can do about a 24 bit field getting
>> split into three movqi rather than a movqi plus a movhi? That happens
>> during RTL expand, I believe.
>
> Yes, this one doesn't look as hopeless as the stor
> On Jul 5, 2018, at 4:44 PM, Eric Botcazou wrote:
>
> ...
> The GIMPLE pass responsible for the optimization simply punts for the "funny-
> endian ordering" of the PDP11. More generally, you shouldn't expect anything
> sparkling for such a peculiar architecture as the PDP11.
Ok. Yet anoth
> On Jun 8, 2018, at 6:16 PM, Jim Wilson wrote:
>
> On Fri, Jun 8, 2018 at 1:12 PM, Paul Koning wrote:
>> Thanks. I saw those sections and interpreted them as support for signal
>> processor style fast hardware loops. If they can be adapted for dbra type
>>
> On Jul 5, 2018, at 12:01 PM, Segher Boessenkool
> wrote:
>
> On Thu, Jul 05, 2018 at 08:45:30AM -0400, Paul Koning wrote:
>> I have a struct that looks like this:
>>
>> struct Xrb
>> {
>>uint16_t xrlen; /* Length of
> On Jul 5, 2018, at 10:44 AM, Florian Weimer wrote:
>
> * Richard Kenner:
>
>>> GCC ChangeLogs don't record the purpose of the change. They say what
>>> changed,
>>> but not why.
>>
>> That depends on how you define "purpose". Let's take a random entry,
>> from a 1999 change of mine:
>>
> On Jul 5, 2018, at 10:43 AM, Florian Weimer wrote:
>
> * Aldy Hernandez:
>
>> Can someone refresh my memory here, what are the remaining arguments for
>> requiring ChangeLog entries?
>
> ChangeLog entries are part of the review, commit messages are not, so
> you end up with surprises ther
I have a struct that looks like this:
struct Xrb
{
uint16_t xrlen; /* Length of I/O buffer in bytes */
uint16_t xrbc; /* Byte count for transfer */
void * xrloc; /* Pointer to I/O buffer */
uint8_t xrci; /* Channel number times 2
I'm running into an ICE in the GIMPLE phase, for gcc.c-torture/compile/386.c,
on pdp11 -mint32. That's an oddball where int is 32 bits (due to the flag) but
Pmode is 16 bits (HImode).
The ICE message is:
../../gcc/gcc/testsuite/gcc.c-torture/compile/386.c: In function ‘main’:
../../gcc/gcc/tes
> On Jun 20, 2018, at 1:16 AM, Jeff Law wrote:
>
> On 06/19/2018 12:55 PM, Paul Koning wrote:
>> Gentlepeople,
>>
>> I have a two-operand divide instruction that takes a double length dividend
>> in a register pair, and produces the quotient in the first
Gentlepeople,
I have a two-operand divide instruction that takes a double length dividend in
a register pair, and produces the quotient in the first register and remainder
in the second.
How do I write a divmod pattern for that? The quotient is easy enough, I write
a match_operand for that re
> On Jun 11, 2018, at 3:04 PM, Jeff Law wrote:
>
> On 06/04/2018 09:02 AM, Paul Koning wrote:
>>
>> ...
>>
>> By "multiple memory operands" do you mean both source and dest in
>> memory?
> Yes and no :-) I suspect no real thought was giv
> On Jun 8, 2018, at 2:29 PM, Jim Wilson wrote:
>
> On 06/08/2018 06:21 AM, Paul Koning wrote:
>> Interesting. The ChangeLog doesn't give any background. I suppose I should
>> plan to approximate the effect of this pattern with a define-peephole2 ?
>
>
> On Jun 8, 2018, at 6:59 AM, Andreas Schwab wrote:
>
> On Jun 07 2018, Paul Koning wrote:
>
>> None of these seem to use that loop optimization, with -O2 or -Os. Did I
>> miss some magic switch to turn on something else that isn't on by default?
>> O
I'm a bit puzzled by the decrement_and_branch_until_zero looping pattern. The
manual described it as a named pattern, through from the description it isn't
clear that it's referenced by name. I see those only in m68k and pa. There
are similar looking but anonymous patterns in pdp11 and vax, s
> On Jun 4, 2018, at 10:09 AM, Jeff Law wrote:
>
> On 06/04/2018 08:06 AM, Paul Koning wrote:
>>
>>
>>> On Jun 4, 2018, at 9:51 AM, Jeff Law wrote:
>>>
>>> On 06/04/2018 07:31 AM, Paul Koning wrote:
>>>> The internals manual in
> On Jun 4, 2018, at 9:51 AM, Jeff Law wrote:
>
> On 06/04/2018 07:31 AM, Paul Koning wrote:
>> The internals manual in its description of the "matching constraint" says
>> that it works for cases where the in and out operands are somewhat
>> different,
The internals manual in its description of the "matching constraint" says that
it works for cases where the in and out operands are somewhat different, such
as *p++ vs. *p. Obviously that is meant to cover post_inc side effects.
The curious thing is that auto-inc-dec.c specifically avoids doing
> On Jun 1, 2018, at 2:40 PM, Jakub Jelinek wrote:
>
> On Fri, Jun 01, 2018 at 02:35:41PM -0400, Paul Koning wrote:
>> during RTL pass: dse2
>> dump file: unwind-dw2-fde.c.288r.dse2
>> ../../../../gcc/libgcc/unwind-dw2-fde.c: In function ‘get_cie_encoding’:
>&
Gentlepeople,
I'm using Eric Botcazou's recipe #2 for the CCmode version of pdp11 -- where
most instructions step on the condition codes so the CC references are inserted
post-reload. As part of that, the compare-elim pass gets rid of compares that
are redundant given that the instruction befo
> On May 31, 2018, at 12:35 PM, Joseph Myers wrote:
>
> On Tue, 29 May 2018, Paul Koning wrote:
>
>> Question about proper target maintainer procedures...
>>
>> The pdp11 target needs udivhi3 in libgcc. There's udivsi3, and it's
>> really e
Question about proper target maintainer procedures...
The pdp11 target needs udivhi3 in libgcc. There's udivsi3, and it's really
easy to tweak those files for HImode. And that works.
Should I add the HI files to the libgcc directory, or under config/pdp11?
There's nothing target specific abo
> On May 29, 2018, at 5:49 AM, Richard Biener
> wrote:
> ...
> It might be a "regression" with the POINTER_MINUS_EXPR introduction.
> You can debug this with gdb when you break on 'pointer_diff'. For me
> on x86_64 this builds a POINTER_DIFF_EXPR: (char *) &s.f - &s.b
> of ptrdiff_t. That a
> On May 28, 2018, at 12:03 PM, Richard Biener
> wrote:
>
> On May 28, 2018 12:45:04 PM GMT+02:00, Andreas Schwab wrote:
>> On Mai 28 2018, Richard Biener wrote:
>>
>>> It means there's no relocation that can express the result of 's.f -
>> &s.b'
>>> and the frontend doesn't consider this
> On May 25, 2018, at 2:11 AM, Eric Botcazou wrote:
>
>> Is this something the back end is responsible for getting right, for example
>> via the machine description file? If so, any hints where to start?
>
> The SUBREG of MEM is invalid at this stage.
Thanks. That pointed me to the problem:
One of my testsuite failures for the pdp11 back end is
gcc.c-torture/compile/930326-1.c which is:
struct
{
char a, b, f[3];
} s;
long i = s.f-&s.b;
It fails with "error: initializer element is not computable at load time".
I don't understand why because it seems to be a perfectly reasonable
I'm doing cleanup on the pdp11 back end to get rid of a
number of ICE in the test suite. One is in
gcc.c-torture/compile/20001221.c -- it works in GCC 4 but
fails in GCC 5 and later.
In the dumps, I see in the output from the expand phase a
large number of memory reference via the "virtual-st
> On May 23, 2018, at 5:46 AM, Richard Biener
> wrote:
>
> ...
>
>> 2. The reported costs for the various insns are
>> r22:HI=['x']6
>> cmp(r22:HI,r23:HI) 4
>> cmp(['x'],['y'])16
>>so the added cost for the memory argument in the cmp is 6 -
> On May 22, 2018, at 3:26 PM, Segher Boessenkool
> wrote:
>
>
> -fdump-rtl-combine-all (or just -da or -dap), and then look at the dump
> file. Does combine try this combination? If so, it will tell you what
> the resulting costs are. If not, why does it not try it?
>
>> Sorry, I'm not v
Gents,
In some targets, like pdp11 and vax, most instructions can reference data in
memory directly.
So when I have "if (x < y) ..." I would expect something like this:
cmpw x, y
bgeq 1f
...
What I actually see, with -O2 and/or -Os, is:
movw x, r0
mo
> On Jan 30, 2018, at 7:00 AM, Segher Boessenkool
> wrote:
>
> On Mon, Jan 29, 2018 at 05:00:00PM -0500, Paul Koning wrote:
>> It's been a few months since I tried to build GCC on my Mac, and in earlier
>> tries it worked fine. I have a log from 20-Sep-2017 t
It's been a few months since I tried to build GCC on my Mac, and in earlier
tries it worked fine. I have a log from 20-Sep-2017 that shows success.
But currently when I do the same configs as before, I get failures about _iconv
being undefined. This is in spite of the fact that I have libiconv
On Nov 26, 2013, at 11:03 AM, Joern Rennecke
wrote:
> On 26 November 2013 15:55, Paul Koning wrote:
>
>> Is there a requirement that all targets must have branch cost that it, at
>> least some of the time, 4 or greater?
>
> Not by design, although there seem to be
On Nov 25, 2013, at 10:25 PM, Jan-Benedict Glaw wrote:
> Hi!
>
> Build log at
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40865
>
> g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
> -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
> -
>
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Richard Guenther
> Sent: Friday, December 02, 2011 9:35 AM
> To: Andrew Haley
> Cc: gcc@gcc.gnu.org
> Subject: Re: volatile correctness: combine vs. target.md
>
> On Fri, Dec 2, 2011 at 1:5
On Jul 19, 2011, at 4:21 AM, Paulo J. Matos wrote:
> On 18/07/11 19:00, Richard Henderson wrote:
>>
>>> "Specifically represent... the carry flag" means using the CCmode
>>> style of condition code handling, right?
>>
>> Yes.
>
> hummm, we are still using the old mode for condition code handli
On Jul 18, 2011, at 12:53 PM, Richard Henderson wrote:
> On 07/18/2011 08:01 AM, Paulo J. Matos wrote:
>> The problem is, if addhi3 expands into two insn:
>> (define_insn "addqi3"
>> [(set (match_operand:HI 0 "nonimmediate_operand" "=c")
>> (plus:HI (match_operand:HI 1 "general_operand"
On Jul 12, 2011, at 6:56 AM, Arnaud Charlet wrote:
>> Why not? If extern "C" is used correctly, the result will work just the
>> same,
>> and the improved type checking etc. would be an asset here just as it is
>> elsewhere.
>
> We don't use much C code, so the extra benefits wouldn't really b
On Jul 12, 2011, at 2:54 AM, Arnaud Charlet wrote:
>> I'm not sure because I don't think we want to compile the C files of the Ada
>> runtime with the C++ compiler. We want to do that only for the compiler.
>
> Right, we definitely don't want to use the C++ compiler for building the
> Ada run-t
On Jul 11, 2011, at 12:53 PM, Arnaud Charlet wrote:
>> When I configure with
>>--enable-build-with-cxx --enable-languages=c,c++,ada
>> I get the appended. The problem is that the Ada code is looking for C
>> symbol names but the names in the .o files are mangled for C++.
>
> Right, or rathe
On Jul 8, 2011, at 1:54 PM, Andrew Pinski wrote:
> On Fri, Jul 8, 2011 at 10:50 AM, Jon Grant wrote:
>> Hello
>>
>> I'm using latest Firefox looking at the onlinedocs with a default
>> Firefox install, default font sizes, no change in zoom level.
>
> Are you sure that this is not a bug in Fire
On Jul 8, 2011, at 1:07 PM, DJ Delorie wrote:
>
> Is there an unwritten rule that the frame pointer must be a single
> hard register? I'm working on a port where $fp is a register pair,
> and I've seen gcc allocate the second register to other things
> (causing all sorts of problems).
Would it
On Jun 17, 2011, at 2:15 PM, Richard Henderson wrote:
> On 06/17/2011 08:54 AM, Paul Koning wrote:
>> In GCC 3.3.3, I had a typedef with attribute((mode(byte))) on it. That
>> worked (the resulting type had size 1).
>>
>> In GCC 4.5.1, this no longer works; the at
In GCC 3.3.3, I had a typedef with attribute((mode(byte))) on it. That worked
(the resulting type had size 1).
In GCC 4.5.1, this no longer works; the attribute is silently ignored. It does
work when used on a variable declaration directly, but for the many lines of
code that relied on the ty
On Jun 17, 2011, at 5:26 AM, Richard Guenther wrote:
> On Fri, Jun 17, 2011 at 11:14 AM, Bingfeng Mei wrote:
>> Hi,
>> I noticed that GCC converts short arithmetic to unsigned short.
>>
>> short foo2 (short a, short b)
>> {
>> return a - b;
>> }
>>
>> In .gimple file:
>>
>> foo2 (short int a
On May 19, 2011, at 6:41 AM, Paul Koning wrote:
>
> On May 19, 2011, at 3:32 AM, Richard Sandiford wrote:
>
>> Paul Koning writes:
>>> ...
>>
>>> 2. In the delay slot fill machinery (reorg.c), I don't see how a
>>> target can supply hooks
On May 19, 2011, at 3:32 AM, Richard Sandiford wrote:
> Paul Koning writes:
>> ...
>
>> 2. In the delay slot fill machinery (reorg.c), I don't see how a
>> target can supply hooks to adjust the picking of one branch over
>> another. In other words, if the
It looks like the machinery that picks MIPS branch-likely instructions (on
processors that don't object to them) is driven purely by their delay slot
annul properties and not at all by branch probability.
That brings up a couple of questions.
1. Assuming it doesn't matter to the delay slot fill
On May 13, 2011, at 8:56 PM, Andrew Pinski wrote:
> On Fri, May 13, 2011 at 5:51 PM, Paul Koning wrote:
>> I was using 4.5.1 which has the bug. I thought later ones have it too, but
>> it looks like I misread the assembly output. (The fix makes a subtle
>> change: beq
On May 13, 2011, at 5:29 PM, Eric Botcazou wrote:
>> rest_of_pass_free_cfg calls df_analyze but it doesn't call
>> df_note_add_problem. Is that the issue? I see that some other passes
>> (like regrename) do a sequence of df_xyz calls.
>
> It does now, you have outdated sources.
I was using 4.
On May 13, 2011, at 5:30 PM, Paul Koning wrote:
>
> On May 13, 2011, at 4:57 PM, Eric Botcazou wrote:
>
>>> Question: that code doesn't appear to touch REG_DEAD notes at all. Is that
>>> right? From the definition of REG_DEAD, it seems that rewriting a later
&
On May 13, 2011, at 4:57 PM, Eric Botcazou wrote:
>> Question: that code doesn't appear to touch REG_DEAD notes at all. Is that
>> right? From the definition of REG_DEAD, it seems that rewriting a later
>> insns to use register x means that a preceding (REG_DEAD x) needs to be
>> deleted. Or m
On May 13, 2011, at 4:57 PM, Eric Botcazou wrote:
>> Question: that code doesn't appear to touch REG_DEAD notes at all. Is that
>> right? From the definition of REG_DEAD, it seems that rewriting a later
>> insns to use register x means that a preceding (REG_DEAD x) needs to be
>> deleted. Or m
In attempting to find out what's wrong in PR 48990 (wrong code for MIPS N32
-O1) it looks to me like the issue is that a register is marked dead, then
still used afterwards. This causes the delay slot fill logic to make a wrong
decision (it brings a load instruction that overwrites the "dead" r
101 - 200 of 363 matches
Mail list logo
