==
GNU Tools Cauldron 2013
http://gcc.gnu.org/wiki/cauldron2013
Call for Abstracts
12-14 July 2013
Google Headquarters
The small memory model will not do since I want to put data at other
distinct addresses above 4G. I also want to place the heap at yet another
address interval. This way it becomes easy to separate out code, data and
heap references, and making sure that pointers are valid. The primary reason
f
On 12/12/12 20:54, Robert Dewar wrote:
On 12/12/2012 2:52 PM, Steven Bosscher wrote:
And as usual: If you use an almost 30 years old architecture, why
would you need the latest-and-greatest compiler technology?
Seriously...
Well the embedded folk often end up with precisely this dichotomy :-)
On Wed, Dec 12, 2012 at 12:56 PM, Leif Ekblad wrote:
> I'm working on OS-adaptations for an OS that would use x86-64 applications
> that are located above 4G, but not in the upper area. Binutils provide a
> function to be able to set the start of text to above 4G, but there are
> problems with GCC
I'm working on OS-adaptations for an OS that would use x86-64 applications
that are located above 4G, but not in the upper area. Binutils provide a
function to be able to set the start of text to above 4G, but there are
problems with GCC when using this memory model.
The first issue has to do
On 12/12/2012 2:52 PM, Steven Bosscher wrote:
And as usual: If you use an almost 30 years old architecture, why
would you need the latest-and-greatest compiler technology?
Seriously...
Well the embedded folk often end up with precisely this dichotomy :-)
But if no sign of 386 embedded chips, t
On Wed, Dec 12, 2012 at 8:39 PM, Robert Dewar wrote:
> On 12/12/2012 1:01 PM, Steven Bosscher wrote:
>>
>> Hello,
>>
>> Linux support for i386 has been removed. Should we do the same for GCC?
>> The "oldest" ix86 variant that'd be supported would be i486.
>
>
> Are there any embedded chips that sti
On 12/12/2012 1:01 PM, Steven Bosscher wrote:
Hello,
Linux support for i386 has been removed. Should we do the same for GCC?
The "oldest" ix86 variant that'd be supported would be i486.
Are there any embedded chips that still use the 386 instruction set?
On Wed, Dec 12, 2012 at 10:01 AM, Steven Bosscher wrote:
> Hello,
>
> Linux support for i386 has been removed. Should we do the same for GCC?
> The "oldest" ix86 variant that'd be supported would be i486.
>
> The benefit would be a few good cleanups:
>
> * PROCESSOR_I386 / TARGET_386 can be remove
Hello,
Linux support for i386 has been removed. Should we do the same for GCC?
The "oldest" ix86 variant that'd be supported would be i486.
The benefit would be a few good cleanups:
* PROCESSOR_I386 / TARGET_386 can be removed
* X86_TUNE_DOUBLE_WITH_ADD can be removed (always true)
* X86_ARCH_C
"H.J. Lu" writes:
>
> i386.c has
>
>{
> /* When not optimize for size, enable vzeroupper optimization for
> TARGET_AVX with -fexpensive-optimizations and split 32-byte
> AVX unaligned load/store. */
This is only for the load, not for deciding whether peeling is
worthw
On Wed, Dec 12, 2012 at 9:06 AM, Christophe Lyon
wrote:
> On 11 December 2012 13:26, Tim Prince wrote:
>> On 12/11/2012 5:14 AM, Richard Earnshaw wrote:
>>>
>>> On 11/12/12 09:56, Richard Biener wrote:
On Tue, Dec 11, 2012 at 10:48 AM, Richard Earnshaw
wrote:
>
> On 11/12/
On 11 December 2012 13:26, Tim Prince wrote:
> On 12/11/2012 5:14 AM, Richard Earnshaw wrote:
>>
>> On 11/12/12 09:56, Richard Biener wrote:
>>>
>>> On Tue, Dec 11, 2012 at 10:48 AM, Richard Earnshaw
>>> wrote:
On 11/12/12 09:45, Richard Biener wrote:
>
>
> On Mon, Dec 10, 2
Hi,
I just noticed a broken link (in case the issue is trivial I may get
around to fixing it myself, but at the moment I don't know):
http://gcc.gnu.org/onlinedocs/gcc/X86-Built-in-Functions.html#X86-Built-in-Functions
(it appers twice)
Cheers,
Paolo.
On Tue, Dec 11, 2012 at 8:49 PM, Steven Bosscher wrote:
> On Tue, Dec 11, 2012 at 6:55 PM, Martin Jambor wrote:
>> some IPA passes do have on-the side vectors with their information
>> about each cgraph node or edge and those are independent GC roots.
>> Not all, but many (e.g. inline_summary_vec
15 matches
Mail list logo
