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
gt;
> (insn 9 8 10 2 (set (reg:CCZ 17 flags)
>(compare:CCZ (reg:SI 61 [ a.2 ])
>(const_int 0 [0]))) ../i386_tests/test_and.c:9 2 {*cmpsi_ccno_1}
> (expr_list:REG_DEAD (reg:SI 61 [ a.2 ])
>(nil)))
>
>
>
>
> Em 27/04/2011 16:20, Paul Koning &
On Apr 27, 2011, at 3:15 PM, cirrus75 wrote:
>
> Hello Ian,
>
> One example is:
>
> insn X : "REG_X = "
> insn X+1 : "MEM(addr) = REG_X"
> insn X+2 : "REGY:CCmode compare(REG_X, const_int 0)"
>
> generated by C code (already posted by me some weeks ago):
> --
>
> int a, b, c, d;
>
On Apr 6, 2011, at 4:56 PM, Joseph S. Myers wrote:
> On Wed, 6 Apr 2011, Paul Koning wrote:
>
>> In i386-gcc 4.5.1, --target-help says that "generic32" and "generic64"
>> are valid values for -march= and -mtune. In fact, those values are
>> rej
In i386-gcc 4.5.1, --target-help says that "generic32" and "generic64" are
valid values for -march= and -mtune. In fact, those values are rejected (even
though there seems to be code in i386.c to handle those values).
paul
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 al
On Mar 25, 2011, at 1:37 PM, DJ Delorie wrote:
>
> "Jayant R. Sonar" 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 has this feature
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 anything.
On Mar 9, 2011, at 8:52 PM, Ian Lance Taylor wrote:
> DJ Delorie 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 people had st
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 tha
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 wri
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 possibi
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).
&
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 va
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.
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.
>
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 ran
On Feb 2, 2011, at 8:32 AM, Richard Guenther wrote:
> On Wed, Feb 2, 2011 at 2:29 PM, Jakub Jelinek 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
>
On Jan 28, 2011, at 8:04 AM, Laurynas Biveinis wrote:
> 2011/1/28 Basile Starynkevitch :
>>> 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 upgrading from 4.5 t
On Jan 27, 2011, at 4:00 PM, Ian Lance Taylor wrote:
> Rainer Orth writes:
>
>> Ian Lance Taylor 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
>>> different mips64 targets, then I thin
> ...
>
> 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 st
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
On Dec 7, 2010, at 10:30 AM, Paulo J. Matos wrote:
> Paul Koning 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_REG
On Dec 7, 2010, at 9:51 AM, Paulo J. Matos wrote:
> Ian Lance Taylor 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 pr
On Dec 2, 2010, at 4:06 PM, H.J. Lu wrote:
> On Thu, Dec 2, 2010 at 1:01 PM, Paul Koning wrote:
>>
>> On Dec 2, 2010, at 3:55 PM, H.J. Lu wrote:
>>
>>> On Thu, Dec 2, 2010 at 12:42 PM, Paul Koning wrote:
>>>>
>>>> On Dec 2, 2010, at 3:
On Dec 2, 2010, at 3:55 PM, H.J. Lu wrote:
> On Thu, Dec 2, 2010 at 12:42 PM, Paul Koning wrote:
>>
>> On Dec 2, 2010, at 3:05 PM, Ian Lance Taylor wrote:
>>
>>> Paul Koning writes:
>>>
>>>> On Dec 2, 2010, at 2:55 PM, Ian
On Dec 2, 2010, at 3:05 PM, Ian Lance Taylor wrote:
> Paul Koning writes:
>
>> On Dec 2, 2010, at 2:55 PM, Ian Lance Taylor wrote:
>>
>>> Paul Koning writes:
>>>
>>>> I'm trying to do a cross-build of gcc 4.5.1. It works fine until I
>
On Dec 2, 2010, at 2:55 PM, Ian Lance Taylor wrote:
> Paul Koning 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
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 configur
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 th
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; c=d
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
On Nov 24, 2010, at 4:04 PM, Joern Rennecke wrote:
> Quoting Richard Guenther :
>
>> 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, so that they can s
On Nov 24, 2010, at 6:45 AM, Richard Guenther wrote:
> On Tue, Nov 23, 2010 at 9:09 PM, Joern Rennecke 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 that replace
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 th
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 possibl
On Nov 8, 2010, at 6:20 AM, Richard Guenther wrote:
> On Mon, Nov 8, 2010 at 12:20 PM, Andi Kleen wrote:
>> Richard Guenther writes:
>>
>>> On Mon, Nov 8, 2010 at 12:03 AM, Andi Kleen wrote:
Andreas Schwab writes:
>
> The asm fails to mention that it modifies *regs.
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 ha
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
Question on what's appropriate...
The doc section on machine dependent constraints is missing the PDP-11 ones.
Is that sort of doc change ok for stage 3? Can I make that as a target
maintainer (it says that this covers "documentation for the port" which I
assume means this kind of content, ri
On Oct 31, 2010, at 2:39 PM, Ian Lance Taylor wrote:
> Paul Koning 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
On Oct 29, 2010, at 5:48 PM, Andrew Pinski wrote:
> On Fri, Oct 29, 2010 at 2:28 PM, Paul Koning 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 s
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
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
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
>>> wrote:
>>>> Question on movmemm:
>>&g
On Oct 25, 2010, at 3:44 PM, Richard Guenther wrote:
> On Mon, Oct 25, 2010 at 11:26 AM, Paul Koning wrote:
>> Question on movmemm:
>>
>> Given
>>
>> extern int *i, *j;
>> void foo (void) { memcpy (i, j, 10); }
>>
>> I would expect to see
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 la
Working on the pdp11 target, I ran into something odd.
It defines REGNO_OK_FOR_BASE_P in a way that seems to match what gccint says
one should do in the "strict" case -- but does so all the time. Specifically,
it says:
#define REGNO_OK_FOR_BASE_P(REGNO) \
((REGNO) < 8 || (unsigned) reg_renum
On Oct 21, 2010, at 8:15 PM, Ian Lance Taylor wrote:
> Frederic Riss 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 registers
>> (with
On Oct 13, 2010, at 9:07 PM, Ian Lance Taylor wrote:
> Paul Koning 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 p
On Oct 13, 2010, at 9:07 PM, Ian Lance Taylor wrote:
> Paul Koning 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 p
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
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
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
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
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,
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
> 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
> 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
> ...
> 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->__
> ...
> >> 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" spe
> Paul Koning 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:
> >
> >
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;
ch
> "Frank" == Frank Ch Eigler 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> r
>>>>> "Joe" == Joe Buck 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 stan
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
> "quick" == quick 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> __restri
> "Rodrigo" == Rodrigo Dominguez 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 change.
GCC do
> "Paolo" == Paolo Bonzini 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 by
I'm seeing messages on this list repeating over and over (several
minutes apart, maybe as much as 15 minutes or so). I'm not sure if
the are just messages from Manuel or also from others.
Is it just me? It seems to be specific to this list...
paul
> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:
Joe> ...OK, consider this case:
Joe> int func1(int); void func2(int); bool test(void); void
Joe> func3(int);
Joe> void func(int arg) { int v1 = func1(arg); func2(v1); if (test())
Joe> { func3(v1); } }
Joe> Here if we put v1 in a register
>>>>> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:
Joe> Paul Koning <[EMAIL PROTECTED]> writes:
>> > That's sufficient for live debugging but not for corefiles. In
>> that > case you do want caller-saved registers, because
ile-time warnings.
Joe> On Wed, Aug 06, 2008 at 01:37:51PM -0400, Paul Koning wrote:
>> So the issue is that two unrelated features are currently combined
>> in a single attribute:
>>
>> 1. This function doesn't return, do the right thing with warnings
>> in
>>>>> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:
Joe> On Wed, Aug 06, 2008 at 11:54:42AM -0400, Paul Koning wrote:
>> I think the space savings in "noreturn" come from not having to
>> save caller-saved registers in the calling functio
> "Mark" == Mark Kettenis <[EMAIL PROTECTED]> writes:
>> Date: Wed, 6 Aug 2008 11:27:36 -0400 From: Daniel Jacobowitz
>> <[EMAIL PROTECTED]>
>>
>> On Wed, Aug 06, 2008 at 07:19:26PM +0400, Sergei Poselenov wrote:
>> > (gdb) bt > #0 0x4004ec0c in raise () from /lib/libc.so.6 > #1
>> 0x40
> "Ralf" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:
Ralf> I feel like I'm stating the obvious, but maybe you're just
Ralf> trying to rediscover feature-based tests: do a test compile
Ralf> that exposes the compiler bug or feature you're looking for.
Ralf> Autoconf provides a framework
I was looking for GCC 3.3.3 just now, and noticed that it doesn't
exist on the generic GNU FTP server or its mirrors
(ftp://ftp.gnu.org/gnu/gcc for example). 3.3.2 and 3.3.4 are there,
as well as lots of other releases, but 3.3.3 is mysteriously missing.
It does exist on the specific GCC mirrors,
> "Robert" == Robert Dewar <[EMAIL PROTECTED]> writes:
Robert> Another general point is that conceptually this is not an
Robert> optimization issue at all.
Robert> The programmer writes code that is undefined according to the
Robert> standard. ...
Robert> To me, the whole notion of thi
> "Paul" == Paul Schlie <[EMAIL PROTECTED]> writes:
Paul> Mark Mitchell wrote:
>> ...
>>
>> And:
>>
>>> Addition or subtraction of a pointer into, or just beyond, an
>>> array object and an integer type produces a result that does not
>>> point into, or just beyond, the same array ob
> "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes:
Ian> "Robert C. Seacord" <[EMAIL PROTECTED]> writes:
>>> What you really mean is, "Use an older GCC or some other compiler
>>> that is known not to take advantage of this optimization."
>>>
>> i think we mean what we say, which is "
> "David" == David Woodhouse <[EMAIL PROTECTED]> writes:
David> On Thu, 2008-03-13 at 13:35 -0400, Daniel Berlin wrote:
>> If by "really weird" you mean "nobody has any real complaints
>> about the way it works and are happy it is close to what they were
>> using before", then yes, they ar
> "kai-gcc" == kai-gcc <[EMAIL PROTECTED]> writes:
kai-gcc> A. There's something similar in the C standard: see
kai-gcc> sig_atomic_t. It might be possible to steal some wording
kai-gcc> from there.
kai-gcc> B. This guarantee - at least as I describe it below - cannot
kai-gcc> work for
> "Segher" == Segher Boessenkool <[EMAIL PROTECTED]> writes:
>> As I said before, I think any words of this form SHOULD NOT be
>> added. All it does is add words to the documentation that provide
>> NO guarantee of anything -- but in a way that will confuse those
>> who don't read it care
> "Segher" == Segher Boessenkool <[EMAIL PROTECTED]> writes:
Segher> Good point. Suggestions for better wording? How does
Segher> "any access to a naturally aligned scalar object in memory
Segher> that is not a bit-field and fits in a general purpose integer
Segher> machine register, wi
> "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
>> We don't have atomic read or atomic write builtins (ok, you could
>> abuse __sync_fetch_and_add (&x, 0) for atomic read and a loop with
>> __sync_compare_and_swap_val for atomic store, but that's a
>> horrible overkill. Being able
I'm really wondering why this is being considered.
A documented property of the form "GCC will use a single instruction
to do X when possible" means exactly nothing. In particular, to call
such a statement a "guarantee" is seriously misleading.
If Linux needs the single-instruction property for
> "Hans-Peter" == Hans-Peter Nilsson <[EMAIL PROTECTED]> writes:
Hans-Peter> On Wed, 30 Jan 2008, Ian Lance Taylor wrote:
>> One issue here is that in some cases const and pure calls can get
>> combined and eliminated even with attribute noinline (unless this
>> changed recently). So in a
> "Joseph" == Joseph S Myers <[EMAIL PROTECTED]> writes:
Joseph> ... There is good coverage for
Joseph> bare-metal ELF targets, but none for bare-metal a.out and
Joseph> COFF targets (perhaps we should consider deprecating all of
Joseph> those, on the presumption that bare-metal use has m
>> The following target architectures have seen no test results
>> posted in the past year: arc, c4x (as listed above), crx, iq2000,
>> mt, pdp11, score, stormy16, vax.
Thanks David.
I fixed my gcc list subscriptions which had become lost at some point
due to malfunctions of internal mailers.
> "shreyas" == shreyas krishnan <[EMAIL PROTECTED]> writes:
shreyas> Hi , I am looking for an efficient data structure to map
shreyas> from a range of addresses to a single address. As it is
shreyas> used at runtime, I want it to be as efficient as possible,
shreyas> with perhaps updaing
> "Mike" == Mike Stump <[EMAIL PROTECTED]> writes:
Mike> On Sep 6, 2005, at 6:16 PM, Gabriel Dos Reis wrote:
>> wrong-code generation that was fixed.
Mike> Customers validate their app and are `happy' with the code
Mike> generation, so this appears to not be a real an issue. Failure
Mik
> "Jonathan" == Jonathan Day <[EMAIL PROTECTED]> writes:
Jonathan> Hi, I am trying to compile a toolchain for a Broadcom SB1
Jonathan> processor in big-endian mode with a host Operating System
Jonathan> of Linux. (The SB1 is a MIPS64, but there is also a
Jonathan> specific SB1 target.) So
>>>>> "Richard" == Richard Henderson <[EMAIL PROTECTED]> writes:
Richard> On Tue, Aug 23, 2005 at 04:32:42PM -0400, Paul Koning wrote:
>> 1. Why do _builtin_ia32_paddusb and similar functions take signed
>> vector arguments, when the hardware p
Two things I'm wondering about:
1. Why do _builtin_ia32_paddusb and similar functions take signed
vector arguments, when the hardware primitive is defined to operate
on unsigned vectors?
2. Why are there no sse equivalents of those functions, ones that
operate on 128 bit values (i.e., pa
> "Mike" == Mike Stump <[EMAIL PROTECTED]> writes:
Mike> On Aug 12, 2005, at 10:39 AM, Dale Johannesen wrote:
>> We had a situation come up here where things are like this
>> (simplified, obviously):
>>
>> c() { char x[100]; }
Mike> I think we should turn off inlining for functions
> "Richard" == Richard Henderson <[EMAIL PROTECTED]> writes:
>> > No it is not, once you take the address (which should be
>> rejected), it > is of type "unsigned int *" and not unaligned
>> variable, passing it to > memcpy assumes the type alignment is the
>> natural alignment.
>>
>> T
>>>>> "Shaun" == Shaun Jackman <[EMAIL PROTECTED]> writes:
Shaun> On 8/2/05, Paul Koning <[EMAIL PROTECTED]> wrote:
>> It sounds like the workaround is to avoid memcpy, and just use
>> variable assignment. Alternatively, cast the pointe
> "Andrew" == Andrew Pinski <[EMAIL PROTECTED]> writes:
>> Yes, this is a compiler bug in the expansion of memcpy, please
>> file a bug report. The solution is for the compiler to notice the
>> memory alignment of the destination and `do-the-right-thing' when
>> it isn't aligned.
Andrew
> "Shaun" == Shaun Jackman <[EMAIL PROTECTED]> writes:
>> 2) Is there padding between the struct members to maintain their
>> natural alignments (on the assumption that the struct's base
>> address is aligned.)
Shaun> There is no padding. The structure is defined as
Shaun> __attribute__(
>>>>> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes:
Dave> Original Message
>> From: Shaun Jackman Sent: 02 August 2005 20:26
>> On 8/2/05, Paul Koning <[EMAIL PROTECTED]> wrote:
>>> One of the things that continues to b
201 - 300 of 363 matches
Mail list logo
