Steven Bosscher writes:
> On Sat, Jun 14, 2014 at 9:36 PM, Richard Sandiford wrote:
>> Using a linked list gives a consistent 2% compile-time improvement for
>> fold-const.ii -O0 and ~1% for various -O2 compiles I tried. The df
>> routines do still show up high on the profile though.
>
> Can you
Just to correct myself here:
Richard Sandiford writes:
> The:
>
> # Handle dependencies between the pre-arch options and the arch option.
> # This should mirror the arch and post-arch code below.
> if { !$arch_test_option_p } {
>
> block should start with something like:
>
> if
Committed as rev. 211685, thanks for the review.
FX
On Sat, 14 Jun 2014, Richard Sandiford wrote:
> To make the final representation change easier, this patch introduces
> macros for iterating over lists of defs, uses and eq_uses. At the
> moment there are three possible keys when accessing df_ref lists:
> the insn rtx (DF_INSN_*), the insn uid (D
On 06/15/2014 01:01 AM, Paolo Carlini wrote:
Committed... but, I don't think we are done yet, because it seems to me
that DR577 means that in C++11 mode we have to accept the typedef?!?
Hmm, apparently so. Might as well apply the DR to C++98 mode as well.
Jason
On 06/13/2014 02:45 PM, Ville Voutilainen wrote:
Yeah, my point was just that unscoped enums (with an explicit underlying type)
as such are eligible for specialization
Yes, but if there is a template definition for the enum available when
the specialization is declared, the enum template is im
On 15 June 2014 16:37, Jason Merrill wrote:
> Yes, but if there is a template definition for the enum available when the
> specialization is declared, the enum template is implicitly instantiated
> along with its containing class, so the specialization is ill-formed because
> you can't define a sp
On Sun, Jun 15, 2014 at 1:27 PM, Hans-Peter Nilsson wrote:
> On Sat, 14 Jun 2014, Richard Sandiford wrote:
>
>> To make the final representation change easier, this patch introduces
>> macros for iterating over lists of defs, uses and eq_uses. At the
>> moment there are three possible keys when ac
ping
To reinforce the message in my earlier email: we can fine-tune the list of
allowed characters in identifiers later, but I’d like to get this patch in
already (so it gets large exposure before the 4.10 release).
FX
> Binding label can be any initialisation expression. Well, only scalar
> Walks of things like DF_REF_INSN_USES were showing up high in the profile
> of a fold-const.ii compilation. These reference lists are represented
> as pointers to null-terminated lists of pointers, and since there's
> little locality when walking all insns, each loop over the uses or defs
> gene
Hello,
I found a problem in GCC on MIPS r5900: When printf() is used with type float,
the converter function __extendsfdf2() is called. Parameters to printf() are
always passed as double and not float. The function __extendsfdf2() calls
itself to convert 32 bit float to 64 bit float. With Linux
> > Walks of things like DF_REF_INSN_USES were showing up high in the profile
> > of a fold-const.ii compilation. These reference lists are represented
> > as pointers to null-terminated lists of pointers, and since there's
> > little locality when walking all insns, each loop over the uses or def
On Sun, 15 Jun 2014, Steven Bosscher wrote:
> On Sun, Jun 15, 2014 at 1:27 PM, Hans-Peter Nilsson wrote:
> > /tmp/hpautotest-gcc0/gcc/gcc/auto-inc-dec.c: In function 'void
> > merge_in_block(int, basic_block_def*)':
> > /tmp/hpautotest-gcc0/gcc/gcc/auto-inc-dec.c:1442: error: 'uid'
> > was not decl
On Sun, 15 Jun 2014, Hans-Peter Nilsson wrote:
> On Sun, 15 Jun 2014, Steven Bosscher wrote:
> > Can you please try:
> >
> > [...]
>
> Thanks. Looks pretty obvious. I was heading for the door with
> just enough time to report the issue, so I didn't actually look
> at the code before. I'll commit
Hello,
this patch continues on my work to move symbol related things into symbol table
rather than having them in decl_with_vis. This time I move TLS_MODEl, that is
relatively easy thing to do. I again followed same scheme as with sections and
comdat groups.
I tried to do this at once with DECL_VI
On Sun, 15 Jun 2014, Hans-Peter Nilsson wrote:
> On Sun, 15 Jun 2014, Hans-Peter Nilsson wrote:
> > On Sun, 15 Jun 2014, Steven Bosscher wrote:
> > > Can you please try:
> > >
> > > [...]
> >
> > Thanks. Looks pretty obvious. I was heading for the door with
> > just enough time to report the iss
The auto-inc-dec.c compilation fix gets us to the next error -- a
runtime failure in the file:
(gdb) run -g -O2 -mlong-double-128 -fbuilding-libgcc
-fno-stack-protector __gcc_bcmp.i
Starting program: /tmp/20140615/gcc/cc1 -g -O2 -mlong-double-128
-fbuilding-libgcc -fno-stack-protector
dw2_asm_output_vms_delta() calls dw2_asm_output_delta() in an abnormal
way, so need add a new function just like vprintf() for printf(), and
then the related call will be in normal way.
The related warning:
../../gcc/gcc/dwarf2asm.c: In function ‘void dw2_asm_output_vms_delta(int,
const char*,
On Sat, Jun 14, 2014 at 7:50 PM, Andrew Pinski wrote:
> On Mon, Feb 24, 2014 at 1:18 AM, Zhenqiang Chen
> wrote:
>> Hi,
>>
>> The patch (http://gcc.gnu.org/ml/gcc-patches/2014-11/msg03622.html) is
>> re-based (the arm port change is stripped as a separate patch), which
>> includes only the middle
Honza,
The cgraph patch in r211600 broke AIX bootstrap again. I cannot find
the corresponding patch in the GCC Patches mailing list, so I do not
see where this was discussed or approved.
With the patch in r211600, the "gen*" programs in stage2 go into an
endless loop.
Please revert these comdat
> Honza,
>
> The cgraph patch in r211600 broke AIX bootstrap again. I cannot find
> the corresponding patch in the GCC Patches mailing list, so I do not
> see where this was discussed or approved.
Sorry, I remember writting mail about this patch but also can't find it. The
patch introduces rese
On Sun, Jun 15, 2014 at 8:23 AM, Bernhard Reutner-Fischer
wrote:
>
>> >> On Tue, May 20, 2014 at 12:42 AM, Janne Blomqvist
>> >> wrote:
>> >>> On Thu, May 15, 2014 at 1:00 AM, Janne Blomqvist
>> >>> wrote:
>> Hi,
>>
>> a common malloc() pattern is "malloc(num_foo * sizeof(foo_t)",
-Original Message-
From: Marat Zakirov [mailto:m.zaki...@samsung.com]
Sent: Friday, June 06, 2014 3:43 PM
To: 'gcc-patches@gcc.gnu.org'
Cc: 'Konstantin Serebryany'; 'Jakub Jelinek'; 'Slava Garbuzov'; Gribov Yury;
'Marat Zakirov'
Subject: [PATCH] Fix for PR 61422
Hi all,
Here's a patch
23 matches
Mail list logo
