Hi!
cpp_peek_token is broken whenever it sees CPP_EOF, as it doesn't back up
the previous tokens (if any) and the CPP_EOF token, so for callers
of cpp_peek_token whenever it returns CPP_EOF it is a fatal condition,
so one really can't peek safely.
cpp_peek_token has apparently been written for th
Hi!
The context sensitive macros are inherently C/C++ specific, so trying to
expand them into anything when preprocessing assembler doesn't make any
sense to me.
Ok for trunk?
2015-04-01 Jakub Jelinek
PR preprocessor/61977
* config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins):
On Wed, Apr 1, 2015 at 10:40 AM, Jakub Jelinek wrote:
> Hi!
>
> The context sensitive macros are inherently C/C++ specific, so trying to
> expand them into anything when preprocessing assembler doesn't make any
> sense to me.
Why are the -c.c cpp builtins defined at all when preprocessing
assembly
On Wed, Apr 01, 2015 at 10:57:10AM +0200, Steven Bosscher wrote:
> On Wed, Apr 1, 2015 at 10:40 AM, Jakub Jelinek wrote:
> > Hi!
> >
> > The context sensitive macros are inherently C/C++ specific, so trying to
> > expand them into anything when preprocessing assembler doesn't make any
> > sense to
Hi,
On 03/31/2015 09:13 PM, Jason Merrill wrote:
On 03/31/2015 01:14 PM, Paolo Carlini wrote:
Note, I took the idea of allowing for current_instantiation ()->decl !=
current_function_decl from some code prepared by Dodji for
-Wunused-local-typedefs
Let's make this a predicate function.
Indee
On Tue, Mar 31, 2015 at 03:11:24PM -0400, Jason Merrill wrote:
> On 03/31/2015 01:22 PM, Marek Polacek wrote:
> >The user *should* have been using . But responding to this
> >with an ICE isn't acceptable either.
> >
> >We do reject wholly incompatible user-defined initializer_list: finish_struct
>
On Wed, Apr 01, 2015 at 12:02:36PM +0200, Paolo Carlini wrote:
> --- cp/pt.c (revision 221795)
> +++ cp/pt.c (working copy)
> @@ -20773,6 +20773,13 @@ current_instantiation (void)
>return current_tinst_level;
> }
>
> +bool
> +instantiating_current_function_p (void)
> +{
> + return (curr
Hi,
expanding AArch64 AdvSIMD builtins, aarch64_simd_expand_builtin puts
return type and arguments types in args[SIMD_MAX_BUILTIN_ARGS] array and
indicates the last argument with SIMD_ARG_STOP. When expanding
4-argument builtin with return value, aarch64_simd_expand_builtin stores
SIMD_ARG_S
Looks good to me. Indeed, I'd support this being an "obvious" fix
--Alan
Maxim Ostapenko wrote:
Hi,
expanding AArch64 AdvSIMD builtins, aarch64_simd_expand_builtin puts
return type and arguments types in args[SIMD_MAX_BUILTIN_ARGS] array and
indicates the last argument with SIMD_ARG_STO
Hi!
This is one possible way to fix another problem with the contextual macros.
When preprocessing e.g. vector at the end of line (both with -mno-altivec
and -maltivec), we cpp_peek_token at least the next token, and unfortunately
during the peek we already call pfile->cb.line_change hook. So we
On Tue, Mar 31, 2015 at 10:04 AM, H.J. Lu wrote:
> On Tue, Mar 31, 2015 at 10:01 AM, Mike Frysinger wrote:
>> On 31 Mar 2015 09:56, H.J. Lu wrote:
>>> On Tue, Mar 31, 2015 at 9:41 AM, Mike Frysinger wrote:
>>> > On 31 Mar 2015 03:10, H.J. Lu wrote:
>>> >> On Mon, Mar 30, 2015 at 11:13 PM, Mike Fr
Jakub Jelinek wrote:
> The context sensitive macros are inherently C/C++ specific, so trying to
> expand them into anything when preprocessing assembler doesn't make any
> sense to me.
Makes sense.
> 2015-04-01 Jakub Jelinek
>
> PR preprocessor/61977
> * config/rs6000/rs6000-c.c
OK, thanks.
Jason
On Wed, Apr 01, 2015 at 07:21:47 +0200, Jakub Jelinek wrote:
> On Wed, Apr 01, 2015 at 02:53:28AM +0300, Ilya Verbin wrote:
> > +/* Similar to gomp_fatal, but release mutexes before. */
> > +
> > +static void
> > +gomp_fatal_unlock (const char *fmt, ...)
> > +{
> > + int i;
> > + va_list list;
>
Hi all,
during debugging another fortran code, I figured that some cases were not yet
met. Especially the case where a class array is in the source= or mold=
expression. This new version of the patch fixes the issue now.
Bootstraps and regtests ok on x86_64-linux-gnu/F20.
Ok for 5.2 trunk?
Rega
On Wed, Apr 01, 2015 at 04:14:05PM +0300, Ilya Verbin wrote:
> On Wed, Apr 01, 2015 at 07:21:47 +0200, Jakub Jelinek wrote:
> > On Wed, Apr 01, 2015 at 02:53:28AM +0300, Ilya Verbin wrote:
> > > +/* Similar to gomp_fatal, but release mutexes before. */
> > > +
> > > +static void
> > > +gomp_fatal_
On 04/01/2015 06:12 AM, Marek Polacek wrote:
On Wed, Apr 01, 2015 at 12:02:36PM +0200, Paolo Carlini wrote:
--- cp/pt.c (revision 221795)
+++ cp/pt.c (working copy)
@@ -20773,6 +20773,13 @@ current_instantiation (void)
return current_tinst_level;
}
+bool
+instantiating_current_fun
Hi,
Trying to build config-list.mk for current trunk.
The box is a stable debian (7.8 it seems) so the OS' ISL is too old
thus i was attempting to use in-tree ISL.
When using an in-tree ISL gcc attempts to determine if it is recent
enough and AFAIU fails to do so since the system's ISL (which we
On Sun, Mar 29, 2015 at 6:45 PM, Jan Hubicka wrote:
> Hi,
> this patch makes inline metric to be
>estimate_speedup
> (over)
> edge_growth^2*overall_growth
>
> This is intended to make stronger push on inliner to preffer functions with
> smaller growth and d
On 1 April 2015 at 17:53, Tobias Grosser wrote:
> On 04/01/2015 05:09 PM, Bernhard Reutner-Fischer wrote:
>>
>> Hi,
>>
>> Trying to build config-list.mk for current trunk.
>> The box is a stable debian (7.8 it seems) so the OS' ISL is too old
>> thus i was attempting to use in-tree ISL.
>>
>> When
On 04/01/2015 05:09 PM, Bernhard Reutner-Fischer wrote:
Hi,
Trying to build config-list.mk for current trunk.
The box is a stable debian (7.8 it seems) so the OS' ISL is too old
thus i was attempting to use in-tree ISL.
When using an in-tree ISL gcc attempts to determine if it is recent
enough
This testcase started crashing because the added call to
check_explicit_specialization does a SET_DECL_TEMPLATE_SPECIALIZATION
which wasn't happening previously, and then determine_visibility assumes
that if DECL_USE_TEMPLATE is set, so is DECL_TEMPLATE_INFO. Fixed for
GCC 5 by avoiding the ca
On 01 Apr 2015 05:04, H.J. Lu wrote:
> --- a/config/zlib.m4
> +++ b/config/zlib.m4
> @@ -9,8 +9,10 @@ AC_DEFUN([AM_ZLIB],
>zlibinc="-I\$(srcdir)/../zlib"
>AC_ARG_WITH(system-zlib,
>[AS_HELP_STRING([--with-system-zlib], [use installed libz])],
> - zlibdir=
> - zlibinc=
> + if test x$w
On April 1, 2015 6:54:31 PM GMT+02:00, Mike Frysinger wrote:
>On 01 Apr 2015 05:04, H.J. Lu wrote:
>> --- a/config/zlib.m4
>> +++ b/config/zlib.m4
>> @@ -9,8 +9,10 @@ AC_DEFUN([AM_ZLIB],
>>zlibinc="-I\$(srcdir)/../zlib"
>>AC_ARG_WITH(system-zlib,
>>[AS_HELP_STRING([--with-system-zlib],
On 01 Apr 2015 19:05, Bernhard Reutner-Fischer wrote:
> On April 1, 2015 6:54:31 PM GMT+02:00, Mike Frysinger wrote:
> >On 01 Apr 2015 05:04, H.J. Lu wrote:
> >> --- a/config/zlib.m4
> >> +++ b/config/zlib.m4
> >> @@ -9,8 +9,10 @@ AC_DEFUN([AM_ZLIB],
> >>zlibinc="-I\$(srcdir)/../zlib"
> >>A
On Wed, Apr 1, 2015 at 9:54 AM, Mike Frysinger wrote:
> On 01 Apr 2015 05:04, H.J. Lu wrote:
>> --- a/config/zlib.m4
>> +++ b/config/zlib.m4
>> @@ -9,8 +9,10 @@ AC_DEFUN([AM_ZLIB],
>>zlibinc="-I\$(srcdir)/../zlib"
>>AC_ARG_WITH(system-zlib,
>>[AS_HELP_STRING([--with-system-zlib], [use
On Wed, Apr 01, 2015 at 15:20:25 +0200, Jakub Jelinek wrote:
> On Wed, Apr 01, 2015 at 04:14:05PM +0300, Ilya Verbin wrote:
> > I was worried about the following scenario:
> > 1. Thread 1 in GOMP_target locks device 1.
> > 2. Thread 2 in GOMP_target locks device 2 and calls gomp_fatal.
> > 3. GOMP_
Hello!
Attached patch fixes invalid atomic_storedi_fpu predicate
(match_operand:DI 1 "register_operand" "x,m,?r").
This predicate is not compatible with memory constraint.
While at this, I also changed expanders to accept memory operands
that can be handled by *_fpu instructions. To avoid unwan
On 04/01/2015 07:24 AM, Jakub Jelinek wrote:
Below is one possible fix for that, another option is introduce another
pfile->state or pfile field for that,
I notice that pfile->state.skipping suppresses the line change as well
as various diagnostics that also seem inappropriate for peeking.
Pe
On Wed, Apr 01, 2015 at 04:23:12PM -0400, Jason Merrill wrote:
> On 04/01/2015 07:24 AM, Jakub Jelinek wrote:
> >Below is one possible fix for that, another option is introduce another
> >pfile->state or pfile field for that,
>
> I notice that pfile->state.skipping suppresses the line change as we
Hi,
gcc/c-family/c-cppbuiltin.c
In file included from ./tm.h:21:0,
from
../../../../../../home/me/src/gcc-5.0.mine/gcc/c-family/c-cppbuiltin.c:23:
../../../../../../home/me/src/gcc-5.0.mine/gcc/c-family/c-cppbuiltin.c:
In function ‘void c_cpp_builtins(cpp_reader*)’:
../../../../..
Bernd,
same for c6x for unk_isa, fwiw.
thanks,
On 1 April 2015 at 23:34, Bernhard Reutner-Fischer
wrote:
> Hi,
>
> gcc/c-family/c-cppbuiltin.c
> In file included from ./tm.h:21:0,
> from
> ../../../../../../home/me/src/gcc-5.0.mine/gcc/c-family/c-cppbuiltin.c:23:
> ../../../../
On 9 March 2015 at 00:37, Jan Hubicka wrote:
>>
>> I unforutnately spot another problem. With presence of section anchors we
>> can not increase alignment of symbol that was already placed into the
>> section.
>> I think this is reason why we still have pass_increase_alignments that runs
>> only
On Wed, Apr 1, 2015 at 3:08 AM, Marek Polacek wrote:
> On Tue, Mar 31, 2015 at 03:11:24PM -0400, Jason Merrill wrote:
>> On 03/31/2015 01:22 PM, Marek Polacek wrote:
>> >The user *should* have been using . But responding to
>> >this
>> >with an ICE isn't acceptable either.
>> >
>> >We do reject
On Mon, Mar 30, 2015 at 3:19 PM, Martin Liška wrote:
> On 03/30/2015 07:03 PM, Jan Hubicka wrote:
>>>
>>> Hello.
>>>
>>> Following patch fixed the issue, where we have to check if function
>>> summary
>>> for IPA CP has been already created.
>>>
>>> Tested on x86_64-linux-pc w/o any new regression
>
> Your follow-up patch 88ada5e935d58223ae2d9ce6d0c1c71c372680a8 a.k.a r221269
> added this to emit_local():
>
> static bool
> -emit_local (tree decl ATTRIBUTE_UNUSED,
> +emit_local (tree decl,
> const char *name ATTRIBUTE_UNUSED,
> unsigned HOST_WIDE_INT size ATTRIBUTE_
On Wed, Apr 1, 2015 at 4:40 AM, Jakub Jelinek wrote:
> Hi!
>
> The context sensitive macros are inherently C/C++ specific, so trying to
> expand them into anything when preprocessing assembler doesn't make any
> sense to me.
>
> Ok for trunk?
>
> 2015-04-01 Jakub Jelinek
>
> PR preproce
On 03/31/2015 03:47 AM, Ilya Enkovich wrote:
On 23 Mar 13:19, Ilya Enkovich wrote:
Hi,
May this patch go into trunk at this point? It is very important for
dynamic MPX codes.
Thanks,
Ilya
I additionally documented changes in invoke.texi. OK for trunk?
Thanks,
Ilya
--
gcc/
2015-03-31 Il
>
> This caused:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65654
I will look into it; the assert checks that the expected function growth
match the real growth after inlining, so it is a semi-latent bug hit by this
patch.
Honza
>
> --
> H.J.
This cures an unrecognizable insn ICE by modifying a predicate of
extenddftf2_internal (the only place this predicate is used) to ensure
that rtl optimization passes do not substitute 0.0 for a register with
known 0.0 value, except when VSX is enabled. ie. Don't undo the
necessary register move em
40 matches
Mail list logo
