On 12 October 2012 22:43, Mischa Baars wrote:
> Hi All,
>
> Who can take a first look at this in the morning?
Hi,
I looked, they seem to be some files. Nice.
If you want people to look at them properly you should probably send
them to the gcc-help list and explain why you want people to look at
Snapshot gcc-4.6-20121012 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20121012/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hi All,
Who can take a first look at this in the morning?
Thanks,
Mischa.
function.o: file format elf64-x86-64
Disassembly of section .text:
:
0: c3 ret
function.o: file format elf64-x86-64
Disassembly of section .text:
0
Somewhere it is mentioned that heap is handled conservatively. Does it
mean the algorithm can not disambiguate heap objects all all, or it
can but does not track pointer values stored in heap objects?
How about field sensitivity? For many programs (mostly C++ ones), this
is very important.
For CS
Here's the September 2012 draft of my "Safe arrays and pointers for C"
proposal:
http://www.animats.com/papers/languages/safearraysforc43.pdf
This incorporates most of the substantive issues raised in
previous discussions.
Brief summary:
- Optional "strict mode" via pragma which prohibits some
On Fri, 12 Oct 2012, Jason Merrill wrote:
> > Consider instead the following expansion:
> >
> > __thread void (*i_initialize)(void) = i_init;
>
> That would work too, though it wouldn't have the benefit of link-compatibility
> with __thread (for variables that don't need dynamic initialization)
On Fri, 12 Oct 2012, Manuel López-Ibáñez wrote:
> I am trying to encode the relationship between Wstrict-aliasing and
> Wstrict-aliasing= in the .opt files, and the same for Wstrict-overflow
> and Wstrict-overflow=. However, the parameters of Alias() are taken as
> strings, so we get "3" and "WARN
On 10/11/2012 03:48 PM, Alexandre Oliva wrote:
This is not entirely clear to me; where is i defined in the first place?
Um, it's defined where the user writes the definition, like any other
variable.
Is it i_init that defines and tests i_initialized?
Yes.
Consider instead the following
On Fri, Oct 12, 2012 at 3:37 PM, Diego Novillo wrote:
> On 2012-10-12 04:26 , Richard Biener wrote:
>
>> What's the issue with always returning the changed status? bitmap
>> operations
>> (even more so sbitmap operations) are memory-bound, accumulating one more
>> register isn't speed critial.
>
On 2012-10-12 04:26 , Richard Biener wrote:
What's the issue with always returning the changed status? bitmap operations
(even more so sbitmap operations) are memory-bound, accumulating one more
register isn't speed critial.
Not a big issue, but it was going to be a behaviour change, which we
Hi
I am trying to test and apply Sebastian Huber's arm-rtems patch
and am getting compilation errors in libgcc2.c which originate
in arm.h. I am using the binutils head also.
This is my configure command:
../gcc-svn/configure --enable-threads=rtems --with-gnu-as \
--enable-multilib --disable-
Excellent! Thanks.
Uday.
Richard Biener wrote, On Friday 12 October 2012 03:20 PM:
On Fri, Oct 12, 2012 at 11:46 AM, Uday P. Khedker wrote:
Richard Biener wrote, On Friday 12 October 2012 02:51 PM:
we _always_ see
ssa_name_1 = a;
use (ssa_name_1);
so you have a place to associa
On 10/12/2012 10:55 AM, Mischa Baars wrote:
As can be seen from the objdump output, 64-bit arguments are passed in
32-bit registers
x86_64 clears the upper 32 bit of a 64 bit register if the lower 32 bit
are written to, so this isn't a bug.
--
Florian Weimer / Red Hat Product Security Team
On Fri, Oct 12, 2012 at 11:46 AM, Uday P. Khedker wrote:
>
>
> Richard Biener wrote, On Friday 12 October 2012 02:51 PM:
>
>>
>> we _always_ see
>>
>>ssa_name_1 = a;
>>use (ssa_name_1);
>>
>> so you have a place to associate your flow-sensitive and context-sensitive
>> points-to-info with
Richard Biener wrote, On Friday 12 October 2012 02:51 PM:
we _always_ see
ssa_name_1 = a;
use (ssa_name_1);
so you have a place to associate your flow-sensitive and context-sensitive
points-to-info with (the SSA name). My point is that for _using_ the
points-to info flow-sensitivity p
On Fri, Oct 12, 2012 at 7:41 AM, Uday P. Khedker wrote:
>
>
> Andrew Pinski wrote, On Friday 12 October 2012 10:29 AM:
>
>
>>> Here's an example:
>>>
>>> main()
>>> {
>>> int **p;
>>> int *a, *d;
>>> int w, x;
>>>
>>> a = &w;
>>> f1(a);
>>> p =
On Fri, Oct 12, 2012 at 1:55 AM, Mischa Baars wrote:
> Hi,
>
> Here's a possible bug in the compiler:
>
> As can be seen from the objdump output, 64-bit arguments are passed in
> 32-bit registers
>
> 0040049c :
> 40049c:55 push rbp
> 40049d:48 89 e5
Hi,
Here's a possible bug in the compiler:
As can be seen from the objdump output, 64-bit arguments are passed in
32-bit registers
0040049c :
40049c:55 push rbp
40049d:48 89 e5 movrbp,rsp
4004a0:be 44 44 00 00 mov
On Thu, Oct 11, 2012 at 11:57 PM, Diego Novillo wrote:
> On 2012-10-11 16:25 , Lawrence Crowl wrote:
>>
>> On 10/11/12, Diego Novillo wrote:
>>>
>>> On 2012-10-11 13:26 , Lawrence Crowl wrote:
My only other concern was that the mapping between those function
names and the tasks to
19 matches
Mail list logo
