[PATCH, committed] fix a number of pdp11 target test failures

This fixes a number of test failures due to test cases that are too large for pdp11 and should be skipped. Also one test case that asks for alignment larger than what pdp11 supports. paul 2018-05-25 Paul Koning <n...@arrl.net> * gcc.c-torture/compile/20151204.c

not computable at load time

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- 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

virtual-stack-vars reference not resolved in vregs

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

Re: How do I stop gcc from loading data into registers when that's not needed?

> 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

Re: How do I stop gcc from loading data into registers when that's not needed?

> 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

How do I stop gcc from loading data into registers when that's not needed?

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

Re: Mac now fails to build because of libiconv

> On Jan 30, 2018, at 7:00 AM, Segher Boessenkool <seg...@kernel.crashing.org> > 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.

Mac now fails to build because of libiconv

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

Re: [PATCH] C: underline parameters in mismatching function calls

> On Oct 2, 2017, at 4:05 PM, David Malcolm wrote: > > ... > the C FE currently emits (trunk): > > test.c: In function 'caller': > test.c:5:25: warning: passing argument 2 of 'callee' makes pointer from > integer without a cast [-Wint-conversion] > return callee

Re: [buildrobot] pdp11-aout

On Nov 25, 2013, at 10:25 PM, Jan-Benedict Glaw jbg...@lug-owl.de 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

Re: [buildrobot] pdp11-aout

On Nov 26, 2013, at 11:03 AM, Joern Rennecke joern.renne...@embecosm.com wrote: On 26 November 2013 15:55, Paul Koning paulkon...@comcast.net 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

Re: volatile correctness: combine vs. target.md

-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:59 PM,

Re: splitting add instructions

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 handling. From what

Re: splitting add instructions

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 %0)

Re: C++ bootstrap of GCC - still useful ?

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-time.

Re: C++ bootstrap of GCC - still useful ?

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 be useful

Re: C++ bootstrap of GCC - still useful ?

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 rather than we

Re: frame pointer must be single register?

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

Re: onlinedocs formated text too small to read

On Jul 8, 2011, at 1:54 PM, Andrew Pinski wrote: On Fri, Jul 8, 2011 at 10:50 AM, Jon Grant j...@jguk.org 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

Re: [PATCH 4/6] Shrink-wrapping

On Jul 7, 2011, at 11:38 AM, Bernd Schmidt wrote: ... It'd also be nice to get rid of all these big blocks of code that are conditional on preprocessor macros, but I realise you're just following existing practice in the surrounding code, so again it can be left to a future cleanup.

Re: [PATCH 4/6] Shrink-wrapping

On Jul 7, 2011, at 1:00 PM, Jeff Law wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/07/11 10:58, Paul Koning wrote: On Jul 7, 2011, at 11:38 AM, Bernd Schmidt wrote: ... It'd also be nice to get rid of all these big blocks of code that are conditional on preprocessor

Re: RFC: 40 bit integer support

On Jul 1, 2011, at 4:14 PM, Bernd Schmidt wrote: On 07/01/11 22:04, Joseph S. Myers wrote: I should add: make the type, the new mode, the testcases etc. entirely target-specific; target-independent GCC should not need to know or care about the specifics of this type. It's bad enough

Re: [PATCH 04/12] vax: Emit prologue as rtl.

On Jun 30, 2011, at 1:21 PM, Richard Henderson wrote: On 06/29/2011 04:01 PM, Steven Bosscher wrote: How many TARGET_ASM_FUNCTION_{PRO,EPI}LOGUE targets are left anyway? Answering the question that it sounds like you actually asked: 2 or 3. Not that it does us that much good because of the

Re: Why does GCC convert short operation to short unsigned?

On Jun 17, 2011, at 5:26 AM, Richard Guenther wrote: On Fri, Jun 17, 2011 at 11:14 AM, Bingfeng Mei b...@broadcom.com 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,

attribute((mode(byte))) no longer works in typedef

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

Re: attribute((mode(byte))) no longer works in typedef

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 attribute is silently ignored

Re: MIPS branch-likely not tied to branch probability?

On May 19, 2011, at 3:32 AM, Richard Sandiford wrote: Paul Koning paul_kon...@dell.com 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 architecture has branch

Re: MIPS branch-likely not tied to branch probability?

On May 19, 2011, at 6:41 AM, Paul Koning wrote: On May 19, 2011, at 3:32 AM, Richard Sandiford wrote: Paul Koning paul_kon...@dell.com 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

MIPS branch-likely not tied to branch probability?

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

regcprop and REG_DEAD

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

Re: regcprop and REG_DEAD

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 moved to

Re: regcprop and REG_DEAD

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 moved to

Re: regcprop and REG_DEAD

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 insns to use register x means

Re: regcprop and REG_DEAD

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.5.1

Re: regcprop and REG_DEAD

On May 13, 2011, at 8:56 PM, Andrew Pinski wrote: On Fri, May 13, 2011 at 5:51 PM, Paul Koning paul_kon...@dell.com 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 becomes

Re: 'The GNU Compiler for the JavaTM Programming Language' translation

On May 5, 2011, at 2:31 PM, Jonathan Wakely wrote: On 5 May 2011 18:52, Sergei Trofimovich wrote: ... I support your suspiction. Linking to that stuff is harmful. Thanks for checking them, Sergei. Now I'm convinced Bohdan Zograf is a link farmer and should be ignored. It sounds to me

Re: Ping^2 Re: Target header etc. cleanup patch

On Apr 20, 2011, at 5:09 PM, Joseph S. Myers wrote: Ping^2. This patch http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00130.html is still pending review. This version applies cleanly to current trunk. ... pdp11 is fine. Thanks! paul

Re: constraints for push byte on word-aligned stack

On Apr 4, 2011, at 12:04 PM, Peter Bigot wrote: I have a target that supports a push.b x operation that puts a byte onto the stack but pre-decrements the stack pointer by 2 to maintain alignment. FWIW, you might look at the pdp11 target support, since what you describe is done by pdp11 also.

Re: Target header etc. cleanup patch

On Apr 2, 2011, at 1:05 PM, Joseph S. Myers wrote: In the course of trying to work out exactly what target macros there are, I came across various oddities in target headers (and a few in target .c files) that are fixed by this patch * Testing showed that IRA_COVER_CLASSES had not been

Re: Supporting multiple pointer sizes in GCC

On Mar 25, 2011, at 1:37 PM, DJ Delorie wrote: Jayant R. Sonar jayant.so...@kpitcummins.com writes: Is it possible to support multiple pointer sizes (e.g. 16bit, 32bit) which can co-exist in single compilation unit? Whether it is supported in GCC now? Is there any other architecture which

Re: Executing already executed optimization passes again

I don't know the answer to your specific question, but I was wondering: if you think it is useful to do optimization again, I think that means that the transformations you have in mind should be done at an earlier stage. By the time you hit register allocation, it's almost too late for

Re: Using cc (question from avr)

On Mar 9, 2011, at 3:35 PM, Georg-Johann Lay wrote: Paulo J. Matos schrieb: Hi, I am having some trouble really understanding the working of cc_status. In order to understand it better I was looking at the code for avr under gcc 4.3. My assumption is that set_zn, set_* means that an

Re: RFC: target hook to reverse bitfield allocations

On Mar 9, 2011, at 8:52 PM, Ian Lance Taylor wrote: DJ Delorie d...@redhat.com writes: Except that in this case we want to reverse *only* structures that represent peripherals, *not* other structures. I'm sorry, that just seems frigging ridiculous. I'm tempted to agree. I thought

Re: gcc-4.5/4.4: Bug in .subreg1 pass?

On Feb 24, 2011, at 12:46 PM, Eric Botcazou wrote: Maybe the misunderstanding occurs when the mode of the subreg is less than word_size? It would certainly make sense that a subreg write of less than word_size leaves the bits undefined. ie, if word_size is SImode and we had a write to

MIPS: Trouble with address calculation near the useg/kseg boundary

I'm running into a crash caused by mishandling of address calculation of an array element address when that array is near the bottom of kseg0 (0x8000). The code essentially does this foo = v[i - 2].elem; where i is current zero. Assume for now the negative array offset is

Re: MIPS: Trouble with address calculation near the useg/kseg boundary

On Feb 16, 2011, at 5:08 PM, David Daney wrote: On 02/16/2011 01:44 PM, Paul Koning wrote: I'm running into a crash caused by mishandling of address calculation of an array element address when that array is near the bottom of kseg0 (0x8000). The code essentially does

Re: MIPS: Trouble with address calculation near the useg/kseg boundary

On Feb 16, 2011, at 5:25 PM, David Daney wrote: What is the state of your C0_Status[{KX,SX,UX}] bits? 0, 0, 0 It is not really a compiler bug, but rather a defect in the n32 ABI. When using 32-bit pointers you can only do 32-bit operations on them. To do otherwise raises the possibility

Re: RFC: A new MIPS64 ABI

On Feb 15, 2011, at 12:41 PM, David Daney wrote: ... The main work would be in the compiler toolchain and runtime libraries. You'd also need to update gas for la and dla expansion. I am counting gas, ld and libc as part of the 'compiler toolchain' Don't forget GDB. paul

Re: RFC: A new MIPS64 ABI

On Feb 14, 2011, at 7:15 PM, Matt Thomas wrote: On Feb 14, 2011, at 12:29 PM, David Daney wrote: Background: Current MIPS 32-bit ABIs (both o32 and n32) are restricted to 2GB of user virtual memory space. This is due the way MIPS32 memory space is segmented. Only the range from

Re: RFC: A new MIPS64 ABI

On Feb 14, 2011, at 9:14 PM, Joe Buck wrote: On Mon, Feb 14, 2011 at 05:57:13PM -0800, Paul Koning wrote: It seems that this proposal would benefit programs that need more than 2 GB but less than 4 GB, and for some reason really don't want 64 bit pointers. This seems like

Re: Bumping DATESTAMP (was: GCC 4.3.5 Status Report (2010-05-22))

On Feb 2, 2011, at 8:32 AM, Richard Guenther wrote: On Wed, Feb 2, 2011 at 2:29 PM, Jakub Jelinek ja...@redhat.com wrote: On Tue, Feb 01, 2011 at 04:32:51PM +0100, Gerald Pfeifer wrote: On Tue, 1 Feb 2011, Dongsheng Song wrote: The DATESTAMP change could also be in a post-commit hook (doing

Re: Heads up: please help documenting *internal* GCC changes for 4.6

On Jan 28, 2011, at 8:04 AM, Laurynas Biveinis wrote: 2011/1/28 Basile Starynkevitch bas...@starynkevitch.net: Its intention is to mention noteworthy internal changes, i.e. changes interesting for, say, maintainers of backends/frontends outside the tree, and of course plugin developers

Re: libgo multilib issues.

On Jan 27, 2011, at 4:00 PM, Ian Lance Taylor wrote: Rainer Orth r...@cebitec.uni-bielefeld.de writes: Ian Lance Taylor i...@google.com writes: I guess ARCH == mips64 is going to be appropriate for any 64-bit MIPS target. If you need a different syscall_linux_${GOARCH} file for

Re: Proposal for automatic generation of c++ header files

... 2) I like headers because they are specifications (they aren't, but what can I do if one believe so? nothing). I think that's a matter of opinion, and language-specific as well. C is such a loose language that applying the notion of specification is hard. Ada is quite another story.

Re: combine two load insns

On Dec 8, 2010, at 11:37 AM, Jeff Law wrote: On 12/08/10 09:18, Frederic Riss wrote: OK, I see your point, but I tend to think the the odds of the register allocator being able to coalesce the additional DI-SI moves in the pre-IRA approach are by far higher that the odds of having merge

Re: The secondary reload

On Dec 7, 2010, at 9:51 AM, Paulo J. Matos wrote: Ian Lance Taylor i...@google.com writes: [snip] after register allocation. After the second split, no output template should still be #. What do you mean by your last sentence? It somehow makes me think that the splits work at some

Re: The secondary reload

On Dec 7, 2010, at 10:30 AM, Paulo J. Matos wrote: Paul Koning paul_kon...@dell.com writes: I assume you by 'instruction' here mean a define_insn and not a single RTL or assembler instruction. So, assume I have two classes M_REGS and Y_REGS and I cannot move between them except if I

Re: libstdc++ gets configure error in cross builds

On Dec 2, 2010, at 4:06 PM, H.J. Lu wrote: On Thu, Dec 2, 2010 at 1:01 PM, Paul Koning paul_kon...@dell.com wrote: On Dec 2, 2010, at 3:55 PM, H.J. Lu wrote: On Thu, Dec 2, 2010 at 12:42 PM, Paul Koning paul_kon...@dell.com wrote: On Dec 2, 2010, at 3:05 PM, Ian Lance Taylor wrote

libstdc++ gets configure error in cross builds

Gents, I'm trying to do a cross-build of gcc 4.5.1. It works fine until I get to libstdc++v3, where configure blows up with a message saying Link tests are not allowed after GCC_NO_EXECUTABLES. This happens on the checking for shl_load step (line 11221 in configure). I looked at

Re: libstdc++ gets configure error in cross builds

On Dec 2, 2010, at 2:55 PM, Ian Lance Taylor wrote: Paul Koning paul_kon...@dell.com writes: I'm trying to do a cross-build of gcc 4.5.1. It works fine until I get to libstdc++v3, where configure blows up with a message saying Link tests are not allowed after GCC_NO_EXECUTABLES

Re: libstdc++ gets configure error in cross builds

On Dec 2, 2010, at 3:05 PM, Ian Lance Taylor wrote: Paul Koning paul_kon...@dell.com writes: On Dec 2, 2010, at 2:55 PM, Ian Lance Taylor wrote: Paul Koning paul_kon...@dell.com writes: I'm trying to do a cross-build of gcc 4.5.1. It works fine until I get to libstdc++v3, where

Re: libstdc++ gets configure error in cross builds

On Dec 2, 2010, at 3:55 PM, H.J. Lu wrote: On Thu, Dec 2, 2010 at 12:42 PM, Paul Koning paul_kon...@dell.com wrote: On Dec 2, 2010, at 3:05 PM, Ian Lance Taylor wrote: Paul Koning paul_kon...@dell.com writes: On Dec 2, 2010, at 2:55 PM, Ian Lance Taylor wrote: Paul Koning paul_kon

Re: IRA undoing sched1

On Nov 29, 2010, at 9:51 PM, Vladimir Makarov wrote: On 11/29/2010 08:52 PM, Paul Koning wrote: I'm doing some experiments to get to know GCC better, and something is puzzling me. I have defined an md file with DFA and costs describing the fact that loads take a while (as do stores

IRA undoing sched1

I'm doing some experiments to get to know GCC better, and something is puzzling me. I have defined an md file with DFA and costs describing the fact that loads take a while (as do stores). Also, there is no memory to memory move, only memory to/from register. Test program is basically a=b;

Re: RFD: hookizing BITS_PER_UNIT in tree optimizers / frontends

On Nov 24, 2010, at 9:37 PM, Dave Korn wrote: On 24/11/2010 21:31, Joern Rennecke wrote: ... We can add the generator program when we (re-) add a word addressed target, or add a bit addressed one. I do think that this goal is not so far off that we should actually encourage new code to

Re: RFD: hookizing BITS_PER_UNIT in tree optimizers / frontends

On Nov 24, 2010, at 6:45 AM, Richard Guenther wrote: On Tue, Nov 23, 2010 at 9:09 PM, Joern Rennecke amyl...@spamcop.net wrote: If we changed BITS_PER_UNIT into an ordinary piece-of-data 'hook', this would not only cost a data load from the target vector, but would also inhibit optimizations

Re: RFD: hookizing BITS_PER_UNIT in tree optimizers / frontends

On Nov 24, 2010, at 4:04 PM, Joern Rennecke wrote: Quoting Richard Guenther richard.guent...@gmail.com: So, Joern, maybe you can clarify what the benefit is in hookizing BITS_PER_UNIT? The point is that I want to eliminate all tm.h macro uses from the tree optimizer and frontend files,

Re: textual prologue/epilogue

On Nov 15, 2010, at 3:50 PM, Paolo Bonzini wrote: The only targets that are using textual prologues and epilogues are now arc, cris, pdp11 and vax. ARC should probably have been deprecated long ago, any plans to convert the others or (for cris) to flip the default? Learning how to do this

Re: Idea - big and little endian data areas using named address spaces

C++ lets you define explicit-order integer types and hide all the conversions. I used that a couple of jobs ago, back around 1996 or so -- worked nicely, and should work even better now that C++ is more mature. paul On Nov 10, 2010, at 7:00 AM, David Brown wrote: Would it be

Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?

On Nov 8, 2010, at 6:20 AM, Richard Guenther wrote: On Mon, Nov 8, 2010 at 12:20 PM, Andi Kleen a...@firstfloor.org wrote: Richard Guenther richard.guent...@gmail.com writes: On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleen a...@firstfloor.org wrote: Andreas Schwab sch...@linux-m68k.org writes:

Re: Stage 3 question

On Nov 3, 2010, at 4:02 PM, Paul Koning wrote: Question on what's appropriate... More on the same topic: sometimes the words are bug fixes and sometimes regressions. I tend to think of regressions as it worked in version x-1 but it's broken in x. Are long-standing bugs also fair game

Tweaking the pathname for __FILE__

The full pathname in __FILE__ is sometimes more than is desirable. For example, if multiple people may be building software in different working directories, you end up with binaries that have lots of differences in them that obscure real changes. Or it may be that rebuilding the bits we had

Re: help debugging ICE in fortran testsuite (was: TARGET_VALID_POINTER_MODE unused?)

On Oct 31, 2010, at 2:39 PM, Ian Lance Taylor wrote: Paul Koning paul_kon...@dell.com writes: What triggered the question is that I'm trying to debug a testsuite ICE in fortran, pdp11 target, where it aborts in convert_memory_address_addr_space apparently trying to make a 32 bit pointer

Re: TARGET_VALID_POINTER_MODE unused?

On Oct 29, 2010, at 5:48 PM, Andrew Pinski wrote: On Fri, Oct 29, 2010 at 2:28 PM, Paul Koning paul_kon...@dell.com wrote: I see documentation for TARGET_VALID_POINTER_MODE, and I see ports that define it... but I don't see any code that uses it. Ok, there are two issues it seems. First

TARGET_VALID_POINTER_MODE unused?

I see documentation for TARGET_VALID_POINTER_MODE, and I see ports that define it... but I don't see any code that uses it. Did I miss it? paul

Re: movmemm pattern

On Oct 25, 2010, at 9:28 PM, Dave Korn wrote: On 26/10/2010 01:53, Paul Koning wrote: On Oct 25, 2010, at 3:44 PM, Richard Guenther wrote: On Mon, Oct 25, 2010 at 11:26 AM, Paul Koning paul_kon...@dell.com wrote: Question on movmemm: Given extern int *i, *j; void foo (void) { memcpy

Re: movmemm pattern

On Oct 26, 2010, at 1:27 PM, Dave Korn wrote: On 26/10/2010 17:16, Paul Koning wrote: On Oct 25, 2010, at 9:28 PM, Dave Korn wrote: ... What happens if you dereference i and j before the memcpy in foo? Do you then get int-sized shared alignment in movmemM? extern int *i, *j; void foo

movmemm pattern

Question on movmemm: Given extern int *i, *j; void foo (void) { memcpy (i, j, 10); } I would expect to see argument 4 (the shared alignment) to be sizeof(int) since both argument are pointers to int. What I get instead is 1. Why is that? If I have extern int i[10], j[10]; then I do get

Re: movmemm pattern

On Oct 25, 2010, at 3:44 PM, Richard Guenther wrote: On Mon, Oct 25, 2010 at 11:26 AM, Paul Koning paul_kon...@dell.com wrote: Question on movmemm: Given extern int *i, *j; void foo (void) { memcpy (i, j, 10); } I would expect to see argument 4 (the shared alignment) to be sizeof(int

Re: Describing multi-register values in RTL

On Oct 21, 2010, at 8:15 PM, Ian Lance Taylor wrote: Frederic Riss frederic.r...@gmail.com writes: Is it possible to describe multi-register values in RTL when the subparts of the value aren't stored in consecutive registers? For example having a DI value constructed from 2 unrelated SI

Re: Trouble doing bootstrap

On Oct 13, 2010, at 9:07 PM, Ian Lance Taylor wrote: Paul Koning paul_kon...@dell.com writes: My build system doesn't have LD_LIBRARY_PATH defined so whatever is the Linux default would apply. Perhaps I should change that. But it seems strange that configure finds the prerequisites

Trouble doing bootstrap

I've tried a couple of different things but it isn't working and this seems like it should be simple... On my Linux system (CentOS 5.5) I'm trying to do a bootstrap of the current trunk. I have the dependencies (mpc, mfpr, gmp) installed. Did configure, no issues. Did make bootstrap. Stage

Re: Trouble doing bootstrap

On Oct 13, 2010, at 6:41 PM, Dave Korn wrote: On 13/10/2010 22:34, Paul Koning wrote: On my Linux system (CentOS 5.5) I'm trying to do a bootstrap of the current trunk. I have the dependencies (mpc, mfpr, gmp) installed. Did configure, no issues. Did make bootstrap. Stage 1 runs

Re: Trouble doing bootstrap

On Oct 13, 2010, at 6:41 PM, Dave Korn wrote: On 13/10/2010 22:34, Paul Koning wrote: On my Linux system (CentOS 5.5) I'm trying to do a bootstrap of the current trunk. I have the dependencies (mpc, mfpr, gmp) installed. Did configure, no issues. Did make bootstrap. Stage 1 runs

Re: Trouble doing bootstrap

On Oct 13, 2010, at 9:07 PM, Ian Lance Taylor wrote: Paul Koning paul_kon...@dell.com writes: My build system doesn't have LD_LIBRARY_PATH defined so whatever is the Linux default would apply. Perhaps I should change that. But it seems strange that configure finds the prerequisites

Re: GFDL/GPL issues

On Aug 2, 2010, at 7:17 PM, Richard Kenner wrote: We are already having trouble keeping our documentation up-to-date. Some of it is in such a poor shape as to be laughable. Yes, it's mostly our fault, but if we were able to generate documentation by simply extracting it from the code.

RE: memcpy(p,p,len)

That would be a bug. If h1 and h2 were marked __restrict__ then using memcpy to make the assignment is valid, but without that marking h1 may be == h2 so memmove is required. paul -Original Message- From: Joakim Tjernlund [mailto:joakim.tjernl...@transmode.se] Sent: Friday,

RE: BB reorder forced off for -Os

Does -Os mean optimize even if it makes things a bit bigger or does it mean optimize only to make it smaller? If the latter then the current behavior would appear to be the correct one. paul -Original Message- From: Ian Bolton [mailto:bol...@icerasemi.com] Sent: Tuesday,

RE: Overhead in C and C++

i'm working on the topic overhead and codesize in C and C++.  The goal of this work is to find out, why C++ is not as fast as normal C code (in same application). Why do you believe this is true? But already by the beginning we found out something very interesting. The Code: int main(int

RE: Slightly offtpic: why svn stubbornly refuses to listen to ctrl-c?!?

Paolo Carlini wrote: Hi, I mean, why a well designed application should refuse to listen to ctrl-c when something goes wrong? Why every time for some reason it gets stuck, I have to kill it from another shell? That's definitely annoying. Paolo. ... Looks like there's a read

RE: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

... The object type is uint8_t, but accessed as uint32_t. That is undefined. Unless uint8_t is a character type, as I understand it. In which way does it make a difference? For aliasing consideration, only the type of access matters. The aliasing rules treat char specially because

RE: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

... typedef unsigned char uint8_t; typedef unsigned int uint32_t; struct in6_addr { uint8_t __s6_addr[16]; }; static inline int address_in_use (unsigned char *a, struct in6_addr *in6) { if const uint32_t *)(a))[0] == ((const uint32_t *)(in6-__s6_addr))[0]

Missing data alignment on MIPS

This relates to bug 13167 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13617) It looks like the compiler is generating appropriate code but gas isn't doing the right thing with it, at least not consistently. With this test program, compiled with GCC 4.1.2 mipsel-netbsdelf: int i = 3;

RE: Missing data alignment on MIPS

Paul Koning paul_kon...@dell.com writes: It looks like the compiler is generating appropriate code but gas isn't doing the right thing with it, at least not consistently. With this test program, compiled with GCC 4.1.2 mipsel-netbsdelf: int i = 3; char foo[17

Re: Revised GCC Runtime Library Exception

Frank == Frank Ch Eigler f...@redhat.com writes: [...] Since the FSF is the copyright owner, even if your reading is held by someone to be correct, then the FSF's FAQ would count as an additional permission. [...] Frank Is anyone else uncomfortable that an important license is to Frank

missing return value

The other day there was a request for a compile error if you do: int foo(void) { } and the answer was the standard says that this is legal -- after all, you can say 'foo();' so the return value isn't used and it doesn't matter that it's missing. That makes sense. So how about: int foo

Re: missing return value

Joe == Joe Buck joe.b...@synopsys.com writes: Joe On Wed, Apr 01, 2009 at 10:18:32AM -0700, Paul Koning wrote: The other day there was a request for a compile error if you do: int foo(void) { } and the answer was the standard says that this is legal -- after all, you can say 'foo

Re: Use of __restrict__ in g++

quick == quick qu...@sparq.org writes: quick I have two questions regarding the use on __restrict__ quick qualifiers for function arguments in C++: quick 1) How does it interact with volatile? quick Example, given: quick void foo(volatile int* __restrict__ p1, volatile int* quick

RE: Inline Assembly Error: suffix or operands invalid for 'shr'

Rodrigo == Rodrigo Dominguez rodd...@hotmail.com writes: Rodrigo H.J, Thanks for replying but this doesn't answer my Rodrigo question. Shouldn't __asm__ generate the right code without Rodrigo using the %b1 trick? The reason I am asking is I have a 350 Rodrigo line macro which I can't

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

Paolo == Paolo Bonzini bonz...@gnu.org writes: Paolo These are all the !SHIFT_COUNT_TRUNCATED targets. For 4.5 I Paolo would like to improve our RTL canonicalization so that no Paolo out-of-range shifts are ever in the RTL representation. Paolo This in turn means that the description given

<    1   2   3   4   5   >