Hi,
Is it possible to get hold of the calling function (in the compiled
program, not in gcc itself) in c-typeck.c:build_function_call()?
Alternatively, what would be a good place to compare the attributes of
a called function with the attributes of the calling function?
What I'm trying to accompl
On 07/01/2009, Dave Korn wrote:
> Andy Scott wrote:
> > GCC Build One:
> >
> > Again stage3 part of build, and this is what actually stops the build
> > the above issue doesn't seem to (I think it happens in stage 2),
>
>
> That sentence contradicts itself and what you said earlier, doesn't
Quoting Stefan Dösinger :
But since you have to have a new gas anyway, wouldn't it be simpler to
have
a new option for gas to instruct it to choose the opcodes that are
expected
by the win32 applications?
This was my first idea, but Alexandre Julliard(the Wine maintainer) disliked
it and prefer
Quoting Stefan Dösinger :
But since you have to have a new gas anyway, wouldn't it be simpler to
have
a new option for gas to instruct it to choose the opcodes that are
expected
by the win32 applications?
This was my first idea, but Alexandre Julliard(the Wine maintainer) disliked
it and prefer
> >> But since you have to have a new gas anyway, wouldn't it be simpler
> to
> >> have
> >> a new option for gas to instruct it to choose the opcodes that are
> >> expected
> >> by the win32 applications?
> > This was my first idea, but Alexandre Julliard(the Wine maintainer)
> disliked
> > it and
Hi Seongbae,
I was doing some work on profiling for picochip, when i noticed what
looks to me like a bug. It looks to me that using fbranch-probabilities
on the commandline (after a round of profile-generate or profile-arcs)
would just not work on any target. Reason..
Coverage.c:1011
if (f
Quoting Stefan Dösinger :
I talked to Alexandre again, and his main concern wasn't so much the global
flag, but that the existance of the push %ebp; mov %esp, %ebp was still up
to the feelings of the compiler and the moon phase.
So what he wants is something like a msvc_prolog attribute that ma
Jakub Jelinek wrote:
On Wed, Jan 07, 2009 at 11:38:55AM +0100, Paolo Bonzini wrote:
Which version of gcc did you use? gcc 4.1 (maybe and 4.2) will report
error. But gcc 4.3 compiles OK. I tested using x86_64 native gcc from
Debian unstable. __emutls_get_address is defined in libgcc even the
tar
> You don't need to force the frame pointer on, it is sufficient to say
> that
> ebp needs restoring at the end of the function no matter if it looks
> otherwise
> used or not - and you have to take the frame size impact of the saved
> ebp into
> account.
How does this fit together with the stack
On Wed, Jan 7, 2009 at 4:44 PM, Ian Lance Taylor wrote:
> "Ye, Joey" writes:
>
>> From: Ian Lance Taylor [mailto:i...@google.com]:
>>> Therefore, I propose that we do the following:
>>>
>>> 1) Introduce __attribute__ ((aligned (scalar))). This will be
>>>documented as having a fixed value fo
On Thu, Jan 8, 2009 at 7:56 AM, H.J. Lu wrote:
> On Wed, Jan 7, 2009 at 4:44 PM, Ian Lance Taylor wrote:
>> "Ye, Joey" writes:
>>
>>> From: Ian Lance Taylor [mailto:i...@google.com]:
Therefore, I propose that we do the following:
1) Introduce __attribute__ ((aligned (scalar))). T
Quoting Stefan Dösinger :
If the frame pointer is not needed:
mov.s %edi, %edi
push %ebp
mov.s %esp, %ebp
pop %ebp
; Continue normally here. I think that case can't be improved too much,
since the msvc_prolog stuff modifies the base pointer.
If ebp needs to be saved because it contains a use
This is the intended behavior, though now I see that the documentation
isn't very clear.
You need to use -fprofile-use - the typical usage scenario is to
compile with -fprofile-generate
to build an executable to do profile collection, and then compile with
-fprofile-use
to build optimized code usin
Hi Seongbae,
Does that mean that someone cant use the profile just to annotate
branches (and get better code by that), without having to get the
additional baggage of "unroll-loops", "peel-loops" etc?
In my case, i am interested in not bloating the code size, but get any
performance that is t
"H.J. Lu" writes:
>> Given that __attribute__ ((aligned (max))) may change, I don't
>> think it is very useful. A portable generic memory allocator should
>> take an additional argument for alignment.
>>
>
> If we really want the maximum useful alignment for the target machine
> we are compiling
Per Ekman writes:
> Is it possible to get hold of the calling function (in the compiled
> program, not in gcc itself) in c-typeck.c:build_function_call()?
It's in the global variable current_function_decl.
Ian
On Thu, Jan 8, 2009 at 10:15 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>>> Given that __attribute__ ((aligned (max))) may change, I don't
>>> think it is very useful. A portable generic memory allocator should
>>> take an additional argument for alignment.
>>>
>>
>> If we really want the
On Thu, Jan 8, 2009 at 10:11 AM, Hariharan wrote:
> Hi Seongbae,
> Does that mean that someone cant use the profile just to annotate branches
> (and get better code by that), without having to get the additional baggage
> of "unroll-loops", "peel-loops" etc?
You can do that by selectively turning
"H.J. Lu" writes:
> It it hard to guess what the alignment should be for C++ new operator.
> Whatever you choose today may not be appropriate tomorrow
> or for others. I think g++ should issue a warning when new operator
> is used on a type whose alignment greater than MALLOC_ABI_ALIGNMENT:
The
On Thu, Jan 8, 2009 at 10:49 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> It it hard to guess what the alignment should be for C++ new operator.
>> Whatever you choose today may not be appropriate tomorrow
>> or for others. I think g++ should issue a warning when new operator
>> is used o
"H.J. Lu" writes:
> On Thu, Jan 8, 2009 at 10:49 AM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> It it hard to guess what the alignment should be for C++ new operator.
>>> Whatever you choose today may not be appropriate tomorrow
>>> or for others. I think g++ should issue a warning whe
On Thu, Jan 8, 2009 at 11:38 AM, Ian Lance Taylor wrote:
>> For the memory allocator writers, they should provide an interface
>> with a parameter to specify alignment requirement. User can use
>> __attribute__ ((aligned (XXX))) to tell compiler memory alignment.
>
> Think harder about new[] and a
"H.J. Lu" writes:
> We can solve it with
>
> 1. A target should define MALLOC_ABI_ALIGNMENT properly.
> 2. g++ should issue an error when the default new operator
> is used on a type whose alignment is greater than
> MALLOC_ABI_ALIGNMENT.
> 3. It is user's responsibility to provide a new operator
> If ebp needs to be saved because it contains a user variable, it is
> better
> not to pop it in the prologue - pop it in the epilogue instead, and you
> don't
> need to have another save/restore.
Sounds reasonable. Is there any flag I can set to make the epilogue pop ebp?
> This can be done wit
On Thu, Jan 8, 2009 at 12:40 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> We can solve it with
>>
>> 1. A target should define MALLOC_ABI_ALIGNMENT properly.
>> 2. g++ should issue an error when the default new operator
>> is used on a type whose alignment is greater than
>> MALLOC_ABI_AL
On Thu, Jan 8, 2009 at 10:17 PM, H.J. Lu wrote:
> On Thu, Jan 8, 2009 at 12:40 PM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> We can solve it with
>>>
>>> 1. A target should define MALLOC_ABI_ALIGNMENT properly.
>>> 2. g++ should issue an error when the default new operator
>>> is used
On Thu, Jan 8, 2009 at 1:36 PM, Richard Guenther
wrote:
> On Thu, Jan 8, 2009 at 10:17 PM, H.J. Lu wrote:
>> On Thu, Jan 8, 2009 at 12:40 PM, Ian Lance Taylor wrote:
>>> "H.J. Lu" writes:
>>>
We can solve it with
1. A target should define MALLOC_ABI_ALIGNMENT properly.
2. g+
Snapshot gcc-4.3-20090108 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090108/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
"H.J. Lu" writes:
> For 4.4, we can apply my patch:
>
> http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00367.html
>
> and update document with
>
> As in the preceding examples, you can explicitly specify the alignment
> (in bytes) that you wish the compiler to use for a given variable or
> structur
"Richard Guenther" writes:
> I don't think we should encourage more uses of __attribute__((aligned)).
But then how can one write a general purpose portable memory
allocator?
Ian
On Thu, Jan 08, 2009 at 03:35:29PM -0800, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
> > For 4.4, we can apply my patch:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00367.html
> >
> > and update document with
> >
> > As in the preceding examples, you can explicitly specify the alignme
Michael Meissner writes:
>> For that matter, don't we have a problem on x86 GNU/Linux, where
>> malloc returns an 8-byte alignment but attribute((aligned)) is a 16
>> byte alignment?
>
> In that case, malloc should be changed to return items that are 16-byte
> aligned
> if any type needs 16-byte
On Thu, Jan 8, 2009 at 3:35 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> For 4.4, we can apply my patch:
>>
>> http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00367.html
>>
>> and update document with
>>
>> As in the preceding examples, you can explicitly specify the alignment
>> (in bytes)
On Thu, Jan 8, 2009 at 3:35 PM, Ian Lance Taylor wrote:
> "Richard Guenther" writes:
>
>> I don't think we should encourage more uses of __attribute__((aligned)).
>
> But then how can one write a general purpose portable memory
> allocator?
Your C library may provide
int posix_memalign(void **m
"H.J. Lu" writes:
>> For that matter, don't we have a problem on x86 GNU/Linux, where
>> malloc returns an 8-byte alignment but attribute((aligned)) is a 16
>> byte alignment?
>
> I don't think it is the same as MALLOC_ABI_ALIGNMENT.
> attribute((aligned)) is something determined by compiler,
> w
On Thu, Jan 8, 2009 at 5:22 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>>> For that matter, don't we have a problem on x86 GNU/Linux, where
>>> malloc returns an 8-byte alignment but attribute((aligned)) is a 16
>>> byte alignment?
>>
>> I don't think it is the same as MALLOC_ABI_ALIGNMENT
"H.J. Lu" writes:
>> There are many ways to align data without exposing it in the
>> ABI--e.g., the alignment of a global array is not part of the ABI, in
>> that nothing breaks if the alignment is increased. Also, there are
>> many programs which simply don't care about an external ABI.
>>
>
>
Hi,
I am currently working on adding native fixed-point support to the avr
backend. A lot of stuff is working, but there are a few things left,
one of them is conversions from fixed point to floating point.
I have conversions between all integer and fixed point types working
as well as SA to SF
38 matches
Mail list logo
