On 26 September 2006 08:43, Jan Beulich wrote:
Daniel Jacobowitz <[EMAIL PROTECTED]> 25.09.06 18:43 >>>
>> On Mon, Sep 25, 2006 at 05:23:34PM +0200, Jan Beulich wrote:
>>> Can anyone set me strait on why, in the following code fragment
>>>
>>> int x(unsigned);
>>>
>>> struct alt_x {
>>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Sep 25, 2006 at 10:04:51AM +0200, Ricardo FERNANDEZ PASCUAL wrote:
> I am sorry, but I fail to see the relation of this with rpcgen (which
> as far I know is a code generator for the RPC protocol). Am I looking
> at the wrong rpcgen?
It's the
Jan Beulich wrote:-
> Can anyone set me strait on why, in the following code fragment
>
> int x(unsigned);
>
> struct alt_x {
> unsigned val;
> };
>
> #define xalt_x
> #define alt_x(p) x(p+1)
>
> int test(struct x *p) {
> return x(p->val);
> }
>
> the function invoked in t
Consider the attached which sweeps through an array of chars..
1) If a typecast is used (CAST defined), the *src is not updated and
main will see (sz == 0).
2) If no typecast is used, *src is updated, and size == 1.
I expected that *src would be updated in both cases (hence the assert)..
But
Andrew MacLeod wrote on 09/26/06 10:34:
> 1 - eliminate test case (this is the easy choice! :-)
> 2 - keep the testcase, remove the option. (It probably doesn't really
> test anything then, so you might as well remove it)
> 3 - make a new testcase which doesn't require -fno-tree-lrs.
>
#2. It
I've got the new out of ssa rewrite pretty much wrapped up, and in the
process I have removed the -fno-tree-lrs option. This means we can no
longer turn off live range splitting at the tree level. I mentioned I
was planning to remove this a few months ago.
Everything is fine, except for one te
On 9/26/06, Bernd Jendrissek <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Sep 25, 2006 at 10:04:51AM +0200, Ricardo FERNANDEZ PASCUAL wrote:
> I am sorry, but I fail to see the relation of this with rpcgen (which
> as far I know is a code generator for the RPC
Hello,
To address
/* The AIX linker will discard static constructors in object files if
nothing else in the file is referenced [...] */
collect2 on AIX builds the ctor/dtor tables from an explicit scan of
all the objects and libraries.
The scan actually also considers frame tables, so we
>>> Daniel Jacobowitz <[EMAIL PROTECTED]> 25.09.06 18:43 >>>
>On Mon, Sep 25, 2006 at 05:23:34PM +0200, Jan Beulich wrote:
>> Can anyone set me strait on why, in the following code fragment
>>
>> int x(unsigned);
>>
>> struct alt_x {
>> unsigned val;
>> };
>>
>> #define xalt_x
>> #d
"Jan Beulich" <[EMAIL PROTECTED]> writes:
> While, as Andreas also pointed out, the standard is a little vague in
> some of what it tries to explain here, it is in my opinion clearly said
> that the re-scanning restrictions are bound to the macro name, not
> the fact that a function-like macro's e
#define xalt_x
>
>the preprocessor token "x" is an object-like macro standing for "alt_x", so
>when we get to
>
#define alt_x(p) x(p+1)
>
> what the preprocessor sees after the first round of expansion is
>
>#define alt_x(p) alt_x(p+1)
As pointed out before - there is *no* expan
Olivier Hainque <[EMAIL PROTECTED]> writes:
> A possible way to address would be to perform a double scan: the
> current one to discover ctors/dtors only, leaving the frame tables
> alone, and a second one on the resulting executable (past a first link
> phase) to discover the relevant frame table
Adam Dickmeiss <[EMAIL PROTECTED]> writes:
> Consider the attached which sweeps through an array of chars..
>
> 1) If a typecast is used (CAST defined), the *src is not updated and
> main will see (sz == 0).
>
> 2) If no typecast is used, *src is updated, and size == 1.
1) Wrong mailing list.
I've noticed while tinkering with 3.4 and 4.1 that some
code sequences turn out much better in 4.1. However, other
code sequences turn out substantially worse in 4.1.
The most frustrating is the reduction in use of postmodify
addressing modes. It looks like tree-ssa-loop-ivopts converts
a loop
Thank you, the documentation looks good.
Ira Rosen wrote:
>
> @item @code{first_location_in_loop}: Provides information about the first
> location accessed by the data reference in the loop and about the access
> function used to represent evolution relative to this location. This data
> is used
I'm attempting to port GCC to our companys 32bit microprocessor, and I'm
a bit overwhelmed.
Looking through some of the documentation (there's quite a lot of it!) I
can't seem to find the answers to a few questions. Pardon me if they
seem basic and obvious.
We already have an assembler and
On 26 September 2006 20:01, max blomme wrote:
> I'm attempting to port GCC to our companys 32bit microprocessor, and I'm
> a bit overwhelmed.
>
> Looking through some of the documentation (there's quite a lot of it!) I
> can't seem to find the answers to a few questions. Pardon me if they
> seem
On Tuesday 26 September 2006 20:09, Dave Korn wrote:
> On 26 September 2006 20:01, max blomme wrote:
> > I'm attempting to port GCC to our companys 32bit microprocessor, and I'm
> > a bit overwhelmed.
> >
> > Looking through some of the documentation (there's quite a lot of it!) I
> > can't seem to
In gcc's syslimits.h (gsyslimits.h), we do:
/* syslimits.h stands for the system's own limits.h file.
If we can use it ok unmodified, then we install this text.
If fixincludes fixes it, then the fixed version is installed
instead of this text. */
#define _GCC_NEXT_LIMITS_H
On Sep 26, 2006, at 2:36 AM, Olivier Hainque wrote:
/* The AIX linker will discard static constructors in object files
if
nothing else in the file is referenced [...] */
Darwin has this same sort of issue and solves it by not wiring up
ctors/dtors for all these things but instead hav
Tzi-cker Chiueh has developed a low-overhead bounds checking
feature and approached the FSF about having it incorporated in GCC. This
discussion originally was forwarded to the GCC Steering Committee, so I am
redirecting the conversation to the main GCC mailinglist. Hopefully some
members
Mike Stump <[EMAIL PROTECTED]> writes:
> In gcc's syslimits.h (gsyslimits.h), we do:
>
> /* syslimits.h stands for the system's own limits.h file.
> If we can use it ok unmodified, then we install this text.
> If fixincludes fixes it, then the fixed version is installed
> instead of t
I've been tinkering with the autovectorizer. It's really cool.
I particularly like the realignment support.
I've noticed just a few things while tinkering with it (in 4.1.1):
0) The realignment code takes the floor of the unaligned pointer, and we
increment the unaligned pointer in the loop. T
So, a testcase like this:
extern void foo() __attribute__((deprecated));
extern void bar() __attribute__((deprecated));
void foo() {}
void bar()
{
foo();
}
Should we warn on the invocation of foo() since it's also being called
from within a deprecated function? We are today, but I've gott
24 matches
Mail list logo
