> On 06/09/2011 03:48 PM, Jonathan Wakely wrote:
>
> When I'm working on complicated template code and debugging a mixture
> of bugs in my templates and ICEs in g++ caused by my buggy templates I
> sometimes wish I could see a dump of all the templates that the
> compiler is instantiating, so I c
Snapshot gcc-4.5-20110609 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20110609/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 6/9/11, Janis Johnson wrote:
> On 06/09/2011 01:30 PM, Lawrence Crowl wrote:
>> On 6/9/11, Janis Johnson wrote:
>>> On 06/08/2011 01:54 PM, Lawrence Crowl wrote:
On 6/6/11, Janis Johnson wrote:
> On 06/03/2011 11:14 AM, Lawrence Crowl wrote:
>> The PPH project has tests that comp
On 06/09/2011 01:30 PM, Lawrence Crowl wrote:
> On 6/9/11, Janis Johnson wrote:
>> On 06/08/2011 01:54 PM, Lawrence Crowl wrote:
>>> On 6/6/11, Janis Johnson wrote:
On 06/03/2011 11:14 AM, Lawrence Crowl wrote:
> The PPH project has tests that compile two different ways, and
> then c
On 6/9/11, Janis Johnson wrote:
> On 06/08/2011 01:54 PM, Lawrence Crowl wrote:
>> On 6/6/11, Janis Johnson wrote:
>>> On 06/03/2011 11:14 AM, Lawrence Crowl wrote:
The PPH project has tests that compile two different ways, and
then compare the assembly. If either of the compiles fails
On 9 June 2011 21:06, Jason Merrill wrote:
> On 06/09/2011 03:48 PM, Jonathan Wakely wrote:
>>
>> Someone else asked for this the other day on gcc-help
>> (http://gcc.gnu.org/ml/gcc-help/2011-06/msg00193.html) so I thought
>> I'd take a look at implementing it. It turns out that or class
>> templat
On 06/09/2011 03:48 PM, Jonathan Wakely wrote:
Someone else asked for this the other day on gcc-help
(http://gcc.gnu.org/ml/gcc-help/2011-06/msg00193.html) so I thought
I'd take a look at implementing it. It turns out that or class
templates all that's needed is something like:
verbatim ("insta
When I'm working on complicated template code and debugging a mixture
of bugs in my templates and ICEs in g++ caused by my buggy templates I
sometimes wish I could see a dump of all the templates that the
compiler is instantiating, so I can see at which point in a
deeply-nested instantiation things
asharif tools writes:
> On Wed, Jun 8, 2011 at 10:32 PM, Ian Lance Taylor wrote:
>> asharif tools writes:
>>
>>> function:
>>> call __i686.get_pc_thunk.bx
>>> addl $_GLOBAL_OFFSET_TABLE_, %ebx
>>> movl %gs:20, %eax # Stack-guard init
>>> movl %eax, -12(%ebp)
I've updated the original documents on the atomics page
http://gcc.gnu.org/wiki/Atomic/GCCMM to add some clarity in places
(especially in the 'synchronization models' section) and updated some
bitrot.
As mentioned last week, I've added a section on codegen which Aldy has
begun implementing
On Wed, Jun 8, 2011 at 10:32 PM, Ian Lance Taylor wrote:
> asharif tools writes:
>
>> function:
>> call __i686.get_pc_thunk.bx
>> addl $_GLOBAL_OFFSET_TABLE_, %ebx
>> movl %gs:20, %eax # Stack-guard init
>> movl %eax, -12(%ebp) # Stack-guard init
>
>> Now, what
On Thu, 9 Jun 2011 16:12:17 +
Vlad Krylov wrote:
>
> REVISION:= $(srcdir)/REVISION
Assuming you are talking of some svn snapshot, the good way to update it is to
use
./contrib/gcc_update
that script will build the REVISION file correctly (after running svn update).
Regards.
--
Bas
On 9 June 2011 17:12, Vlad Krylov wrote:
>
> Hi all.
>
>
> I see in gcc/gcc/version.c:
>
> /* The complete version string, assembled from several pieces.
> BASEVER, DATESTAMP, DEVPHASE, and REVISION are defined by the
> Makefile. */
>
> In gcc/gcc/Makefile.in:
>
> REVISION := $(srcdir)/REVI
On 06/08/2011 01:54 PM, Lawrence Crowl wrote:
> On 6/6/11, Janis Johnson wrote:
>> On 06/03/2011 11:14 AM, Lawrence Crowl wrote:
>>> The PPH project has tests that compile two different ways, and
>>> then compare the assembly. If either of the compiles fails, the
>>> comparison will fail. We'd l
Hi all.
I see in gcc/gcc/version.c:
/* The complete version string, assembled from several pieces.
BASEVER, DATESTAMP, DEVPHASE, and REVISION are defined by the
Makefile. */
In gcc/gcc/Makefile.in:
REVISION:= $(srcdir)/REVISION
I've created gcc/REVISION file with some number and
Hi,
I have provided a backtrace and a preprocessed file in
PR49344.
Dominique
陳韋任 writes:
>> That documentation is out of date. The CFG is now retained through most
>> of the RTL passes.
>
> You said "through most of the RTLpasses". And I found the CFG
> is freed before other passes in gcc/passes.c.
>
> NEXT_PASS (pass_free_cfg);
> NEXT_PASS (pass_machine_reorg)
Hello,
>
> Can you provide a backtrace and open a bugreport?
Sure, will do that. (I deleted the bootstrap dir so I can not provide
that info immediately though)
Thanks,
Revital
On Thu, Jun 9, 2011 at 2:01 PM, Revital Eres wrote:
> Hello,
>
> I get the following bootstrap failure on ppc64-redhat-linux with trunk
> -r174840
> compiling with -O2 flag..
Can you provide a backtrace and open a bugreport?
Richard.
> Thanks,
> Revital
>
>
> /bin/sh ../../libtool --tag=CC -
Hello,
I get the following bootstrap failure on ppc64-redhat-linux with trunk -r174840
compiling with -O2 flag..
Thanks,
Revital
/bin/sh ../../libtool --tag=CC --mode=compile
/home/eres/mainline/build/./gcc/xgcc
-B/home/eres/mainline/build/./gcc/
-B/home/eres/mainline/build/powerpc64-unknown-
Hi,
My port hits this assertion in loop-iv.c:799:
gcc_assert ((*inner_mode == *outer_mode) != (*extend != UNKNOWN));
It's in the function get_biv_step:
static bool
get_biv_step (df_ref last_def, rtx reg, rtx *inner_step,
enum machine_mode *inner_mode, enum rtx_code *extend,
Hi, Ian
> That documentation is out of date. The CFG is now retained through most
> of the RTL passes.
You said "through most of the RTLpasses". And I found the CFG
is freed before other passes in gcc/passes.c.
NEXT_PASS (pass_free_cfg);
NEXT_PASS (pass_machine_reorg);
NEXT_PASS (
22 matches
Mail list logo
