On Fri, Jun 13, 2008 at 12:49 AM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 12, 2008 at 4:39 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
>> On 2008-06-12, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>>
>>> I have no idea how to make sure, in whopr, that function x sees foobar if
>>> yo
Hi,
The issue is, that for x86_64 the call for a w64 abi function should be
supported. The problem is, that va_list has always the type of the target
and there is no abi specific switching supported. My first idea was to
make the define for va_list_type_node in tree.h overridable for targets,
On 6/12/08 6:49 PM, Daniel Berlin wrote:
On Thu, Jun 12, 2008 at 4:39 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
int N;
int foobar;
int *bar = &foobar;
int **foo = &bar;
x ()
{
int **x = foo;
return **x;
}
All of 'foobar', 'bar' and 'foo' will be in the list of symbols
referenced by x().
On 6/13/08 3:27 AM, Richard Guenther wrote:
But probably pulling them in on-demand is
a more practical approach (after all this huge number of vars is
also the cause of the slowness of alias computation and partitioning
in this testcase).
I agree, and the end result would be the same. By the
On Fri, Jun 13, 2008 at 12:29 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On 6/13/08 3:27 AM, Richard Guenther wrote:
>
>> But probably pulling them in on-demand is
>> a more practical approach (after all this huge number of vars is
>> also the cause of the slowness of alias computation and part
Hi,
I wanted to give a small update on what has been done on the CLI branch
(gcc svn repository branches/st) before the summit.
I will not be able to be there,
have fun :)
What we have done lately
- added binutils for cil as simple wrappers on DotGnu binutils
simplifies build of a toolchain
On Thu, Jun 12, 2008 at 01:10:10PM -0700, David Daney wrote:
>>> Among the versions of GCC that can build the current kernel, will any
>>> fail on this code because the "i" constraint cannot be matched when
>>> expanded to RTL?
>>
>> Someone will point this out if I don't, so for avoidance of doub
Showed up for v850, iq2000, and m32c... Manual compilation results in
zero warnings.
--- Start of forwarded message ---
Date: Fri, 13 Jun 2008 11:21:27 -0400
From: DJ Delorie <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Results for 4.4.0 20080613 (experimental) [trunk re
Ian Lance Taylor wrote:
I think that when it is reasonably stable it should move into a .texi
file in the source code. That is there the gcc internals manual
lives.
I would not be averse to moving the entire internals manual to the web
in some form. But having it in two places does not seem l
Jonathan Wakely wrote:
Hi Volker, thanks for picking these issues up. I told Manuel I'd
review the rest of the remaining pedwarns, but haven't had time to do
it either.
Just to chime in here: Volker, I agree with your comments.
Jonathan, Manuel, if you would please make the time to finish this
2008/6/13 Mark Mitchell <[EMAIL PROTECTED]>:
> Jonathan Wakely wrote:
>>
>> Hi Volker, thanks for picking these issues up. I told Manuel I'd
>> review the rest of the remaining pedwarns, but haven't had time to do
>> it either.
>
> Just to chime in here: Volker, I agree with your comments.
>
> Jona
Status
==
Congratulations and Kudos to Jakub for the GCC 4.3.1 release!
The GCC 4.3 open for commits under normal release branch rules.
Unfortunately, after getting to zero P1s, some more wrong-code and
ice-on-valid errors have reappeared. So, the bug counts are up a bit.
Quality Data
=
Snapshot gcc-4.4-20080613 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080613/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
> I should start posting these to the testing list. Lots of m16c
> improvements, but some m32c regressions. I haven't tried to diagnose
> these yet, but if nobody claims it's their fault I will ;-)
>
> Anyone know why the regressions happened?
>
> PASS-FAIL: gcc.c-torture/execute/builtins/vspr
14 matches
Mail list logo
