Hello,
could you please approve this patch:
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02664.html
As it looks like, it fixes the problem reported under PR59134,
which is the expander enters infinite recursion while it tries to violate the
C++ memory model.
The memory context has still the st
On Thu, Nov 14, 2013 at 06:29:50PM -0700, Aldy Hernandez wrote:
> >Well, if you don't change anything in omp-low.c, then it wouldn't diagnose
> >setjmp call in #pragma simd, but given that also the OpenMP 4.0 spec
> >requires that #pragma omp simd doesn't contain calls to setjmp or longjmp
> >(ditt
On 11/14/13 15:19, Diego Novillo wrote:
On Thu, Nov 14, 2013 at 5:12 PM, Jeff Law wrote:
On 11/14/13 13:28, Diego Novillo wrote:
Functions in each corresponding .c file got moved to those
headers and others that already existed. I wanted to make this
patch as mechanical as possible, so I made
I'm still unable to bootstrap the ia64 port if I back out Kirill's most
recent patch.
The erroneous-path-isolation code has exposed a latent bug in the RTL
if-conversion pass which runs after combine (ie no longer in cfglayout
mode).
We have this as we leave combine:
(insn 107 106 10
On 11/06/13 11:33, Joseph S. Myers wrote:
When bootstrapping a cross toolchain with GCC and glibc, it's
desirable to keep down the number of GCC builds needed: to be able to
build an initial static-only C-only GCC, use that to build glibc, and
then build the full compiler with the resulting glibc
On Thu, Nov 14, 2013 at 1:16 PM, H.J. Lu wrote:
> On Thu, Nov 14, 2013 at 6:16 AM, Arnaud Charlet wrote:
>>> I also changed s-osinte-posix.adb and s-osprim-posix.adb
>>> for x32. They aren't Linux specific. What should I do with
>>> them?
>>
>> I would use the time_t type defined in s-osinte* (
On Wed, Nov 13, 2013 at 5:12 PM, Bernd Edlinger
wrote:
> On Tue, 12 Nov 2013 17:50:27, Sriraman Tallam wrote:
>>
>> On Tue, Nov 12, 2013 at 5:17 PM, Sriraman Tallam wrote:
>>> On Tue, Nov 12, 2013 at 2:53 PM, Bernd Edlinger
>>> wrote:
Hi,
On Tue, 12 Nov 2013 10:30:16, Srirama
On Wed, Nov 13, 2013 at 7:25 AM, Uros Bizjak wrote:
> On Tue, Nov 12, 2013 at 8:52 AM, Uros Bizjak wrote:
>
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x1c]
>>
FAIL: runtime/pprof
gmake[2]: *** [runtime/pprof/check] Error
On 11/14/2013 05:16 PM, Joseph S. Myers wrote:
On Thu, 14 Nov 2013, Diego Novillo wrote:
This patch contains the mechanical side-effects from
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01663.html
There are rather a lot of "Include tm.h" changes here - especially in
front ends, where we've tr
On Thu, Nov 14, 2013 at 02:33:00PM -0700, Jeff Law wrote:
> On 11/14/13 14:14, Richard Biener wrote:
> >>
> >>I'm just pointed out that of all the stuff you changed, these were the
> >>only ones I saw where lifetimes were changed significantly.
> >
> >I still ask why we need a new type and cannot p
C99, but not C11, C++98, C++03 or C++11, disallows universal character
names for digits starting identifiers. The cpplib logic for this gets
the "digit" property from Unicode data, but that data disagrees with
C99 Annex D, which considers Roman numerals (2160-2182), IDEOGRAPHIC
NUMBER ZERO (3007)
Hi
This patch adds the support to two non-isomorphic operations addsub
and subadd for SLP vectorizer. More non-isomorphic operations can be
added later, but the limitation is that operations on even/odd
elements should still be isomorphic. Once such an operation is
detected, the code of the operat
I've applied this patch backport to 4.7 branch to fix "make install-pdf"
there with newer Texinfo tools.
2013-11-15 Joseph Myers
Backport from mainline:
2012-06-29 Andreas Schwab
* copying-lib.texi (Library Copying): Don't use @heading inside
@enumerate.
I
On 11/14/2013 06:56 PM, Jeff Law wrote:
On 11/14/13 16:00, Andrew MacLeod wrote:
I was bootstrapping Ada as well until the end of last week. It seems
to be broken right now, so I had turned Ada off until the issue is
resolved.
Ada should be working again... At least on x86_64. I'm still lo
On 11/14/13 16:00, Andrew MacLeod wrote:
I was bootstrapping Ada as well until the end of last week. It seems
to be broken right now, so I had turned Ada off until the issue is
resolved.
Ada should be working again... At least on x86_64. I'm still looking
at it on Itanic, but I suspect you
> > 2013-11-14 Uros Bizjak
> >
> > * lto-streamer-in.c (input function): Call cgraph_create_node if
> > cgraph_get_node failed.
> >
> > Tested with lto-profiledbootstrap on x86_64-pc-linux-gnu, regression
> > tested also with -m32 [1].
> >
> > OK for mainline?
OK (though it is a bit ugl
Hi,
Complementing the recent change to enable FP MADD instructions on
MIPS32r2 processors in the 32-bit FPR mode (CP0.Status.FR=0) here's one to
enable FP reciprocal instructions (RECIP.fmt and RSQRT.fmt) in that case
as well. Architecture documents have been amended to make it unambiguous
t
Hi,
Complementing the recent change to enable FP MADD instructions on
MIPS32r2 processors in the 32-bit FPR mode (CP0.Status.FR=0) here's one to
enable FP ordinary indexed memory access (i.e. LWXC1, SWXC1, LDXC1 and
SDXC1) instructions in that case as well. Architecture documents have
been a
On 11/14/2013 05:06 PM, H.J. Lu wrote:
On Thu, Nov 14, 2013 at 8:34 AM, Andrew MacLeod wrote:
On 11/14/2013 11:23 AM, Michael Matz wrote:
Hi,
On Thu, 14 Nov 2013, Andrew MacLeod wrote:
I think if following through with the whole plan there would (and
should) be nothing remaining that could
On Thu, Nov 14, 2013 at 5:07 PM, Ulrich Weigand wrote:
> Here's a patch to add documentation along the lines of what we have
> for the longdouble switches.
>
> Doc build tested on powerpc64-linux.
>
> David, would that be OK for mainline, or do have other suggestions?
I don't think that the word
On Thu, Nov 14, 2013 at 3:51 AM, Eric Botcazou wrote:
>> Here is a patch. OK to install?
>
> Yes, thanks.
>
> --
> Eric Botcazou
It doesn't work:
ERROR: gnat.dg/specs/addr1.ads: syntax error in target selector "xfail
mips*-*-* { { i?86-*-* x86_64-*-* } && x32 }" for " dg-bogus 24
"(alignment|er
On Thu, 14 Nov 2013, Diego Novillo wrote:
> These are due to builtins.h. The structs defined in there need
> FIRST_PSEUDO_REGISTER. This means that we have parts of builtins.h
> that are OK for FEs and others that aren't. This is not good.
>
> The best alternative for this change is to leave t
On 11/14/13 10:49, David Malcolm wrote:
FWIW, I prefer the downcasts to adding virtual functions; what I've
tried to do is create a very direct mapping from the status quo,
introducing inheritance to gain the benefits listed earlier in the
thread, whilst only changing "surface syntax".
I underst
This patch changes libgo so that if the executable filename does not
have a '/', it does not use that name for the backtrace library. This
is the case when an executable is found on PATH. In that case, there is
no particular reason to believe that a file with that name in the
current directory is
On Thu, Nov 14, 2013 at 5:16 PM, Joseph S. Myers
wrote:
> On Thu, 14 Nov 2013, Diego Novillo wrote:
>
>> This patch contains the mechanical side-effects from
>> http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01663.html
>
> There are rather a lot of "Include tm.h" changes here - especially in
> front
On Thu, Nov 14, 2013 at 5:12 PM, Jeff Law wrote:
> On 11/14/13 13:28, Diego Novillo wrote:
>>
>> Functions in each corresponding .c file got moved to those
>> headers and others that already existed. I wanted to make this
>> patch as mechanical as possible, so I made no attempt to fix
>> problems
On Thu, 14 Nov 2013, Diego Novillo wrote:
> This patch contains the mechanical side-effects from
> http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01663.html
There are rather a lot of "Include tm.h" changes here - especially in
front ends, where we've tried to eliminate tm.h calls, and put comments
I did not add all headers factored out of tree.h because it is unclear
(and impossible to tell) what plugins need. This adds the one header
used by the plugins in the testsuite.
This will be changing quite dramatically as we progress with the
header refactoring.
2013-11-14 Diego Novillo
This patch from Chris Manghane changes the Go frontend to use the
backend interface for comparisons. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 8a3737dd11fd go/expressions.cc
--- a/go/expressions.cc Thu Nov 14 12:18:10 2013 -0800
+++ b/go/e
On 11/14/13 13:28, Diego Novillo wrote:
Functions in each corresponding .c file got moved to those
headers and others that already existed. I wanted to make this
patch as mechanical as possible, so I made no attempt to fix
problems like having build_addr defined in tree-inline.c. I left
that for
Joseph Myers wrote:
> On Tue, 12 Nov 2013, Ulrich Weigand wrote:
> > > > Therefore, it is introduces via a new pair of options
> > > >-mabi=elfv1 / -mabi=elfv2
> > > > where -mabi=elfv1 select the current Linux ABI, and -mabi=elfv2
> > > > selects the new one.
> > >
> > > New command-line opti
On Thu, Nov 14, 2013 at 8:34 AM, Andrew MacLeod wrote:
> On 11/14/2013 11:23 AM, Michael Matz wrote:
>>
>> Hi,
>>
>> On Thu, 14 Nov 2013, Andrew MacLeod wrote:
>>
I think if following through with the whole plan there would (and
should) be nothing remaining that could be called a gimple
On 11/14/13 04:52, Eric Botcazou wrote:
Hi,
we have a test in the gnat.dg testsuite (stack_usage1.adb) which checks that
the allocation of big temporaries created in non-overlapping blocks on the
stack is optimal, i.e. that they share a stack slot. It is run at -O0 and
passes. If you run it at
On 10/31/13 10:26, David Malcolm wrote:
* Makefile.in (GIMPLE_H): Add dep on is-a.h.
Not asking you, but I'd like to hope many of the *_H things in
Makefile.in should be going away...
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index cc88fb8..7fbb533 100644
--- a/gcc/Makefile.in
On 11/14/13 13:46, Richard Sandiford wrote:
pp_c_character_constant only calls pp_p_char for values that fit into
a HWI of the constant's signedness (i.e. an unsigned HWI if TYPE_UNSIGNED
and a signed HWI otherwise). But pp_c_character_constant is only called by:
case INTEGER_CST:
{
On 11/14/13 14:14, Richard Biener wrote:
I'm just pointed out that of all the stuff you changed, these were the
only ones I saw where lifetimes were changed significantly.
I still ask why we need a new type and cannot put this functionality into
bitmap_head itself.
Given that bitmap is just a
On Thu, Nov 14, 2013 at 6:16 AM, Arnaud Charlet wrote:
>> I also changed s-osinte-posix.adb and s-osprim-posix.adb
>> for x32. They aren't Linux specific. What should I do with
>> them?
>
> I would use the time_t type defined in s-osinte* (all POSIX implementations
> of s-osinte* have such defin
Jeff Law wrote:
>On 11/14/13 04:04, tsaund...@mozilla.com wrote:
>> From: Trevor Saunders
>>
>> Hi,
>>
>> this patch adds and starts to use a class auto_bitmap, which is a
>very thin
>> wrapper around bitmap. Its advantage is that it takes care of
>delocation
>> automatically. So you can do thi
Sergey Ostanevich wrote:
>this is only for the whole file? I mean to have a particular loop
>vectorized in a
>file while all others - up to compiler's cost model. is there such a
>machinery?
No, there is not.
Richard.
>Sergos
>
>On Thu, Nov 14, 2013 at 12:39 PM, Richard Biener
>wrote:
>> On We
Apart from the case in the C front end, there are 4 calls to host_integerp
with a variable "pos" argument. These "pos" arguments are all taken from
TYPE_UNSIGNED. In the dwarf2out.c case we go on to require:
simple_type_size_in_bits (TREE_TYPE (value)) <= HOST_BITS_PER_WIDE_INT
|| host_integ
This patch fixes two issues, the most important issue is the related to
the Ada build failures on the trunk.
When non-call-exceptions is on, most memory references potentially
throw. As a result those statements end basic blocks. This causes
checking failures when the __builtin_trap is plac
On Thu, Nov 14, 2013 at 6:16 AM, Arnaud Charlet wrote:
>> I also changed s-osinte-posix.adb and s-osprim-posix.adb
>> for x32. They aren't Linux specific. What should I do with
>> them?
>
> I would use the time_t type defined in s-osinte* (all POSIX implementations
> of s-osinte* have such defin
Now with the patch attached.
On Thu, Nov 14, 2013 at 9:49 PM, Uros Bizjak wrote:
> On Thu, Nov 14, 2013 at 7:16 PM, Uros Bizjak wrote:
>
> Attached patch fixes lto-profiledbootstrap, introduced by:
>
> 2013-11-12 Martin Jambor
>
> * cgraph.c (cgraph_get_create_node): Do what
>
On Thu, Nov 14, 2013 at 7:16 PM, Uros Bizjak wrote:
Attached patch fixes lto-profiledbootstrap, introduced by:
2013-11-12 Martin Jambor
* cgraph.c (cgraph_get_create_node): Do what
cgraph_get_create_real_symbol_node used to do.
(cgraph_get_create_real_symbol_node): Re
pp_c_character_constant only calls pp_p_char for values that fit into
a HWI of the constant's signedness (i.e. an unsigned HWI if TYPE_UNSIGNED
and a signed HWI otherwise). But pp_c_character_constant is only called by:
case INTEGER_CST:
{
tree type = TREE_TYPE (e);
...
On 11/14/13 07:52, Richard Biener wrote:
Another advantage of this class is it puts the bitmap_head struct on the stack
instead of mallocing it or using a obstack.
Hm, but then eventually you increase the lifetime of the bitmap
until the scope closes.
Yea, but often that's when we're releasing
On 11/14/13 04:04, tsaund...@mozilla.com wrote:
From: Trevor Saunders
Hi,
this patch adds and starts to use a class auto_bitmap, which is a very thin
wrapper around bitmap. Its advantage is that it takes care of delocation
automatically. So you can do things like
int
f ()
{
auto_bitmap x
On Fri, Nov 15, 2013 at 06:26:28AM +1000, Richard Henderson wrote:
> On 11/15/2013 06:13 AM, Jakub Jelinek wrote:
> > On Fri, Nov 15, 2013 at 05:48:27AM +1000, Richard Henderson wrote:
> >> Pointers are certainly a decent fallback that would always be compatible,
> >> but I wonder if we need go tha
On Tue, Nov 12, 2013 at 7:16 AM, Rainer Orth
wrote:
> Ian Lance Taylor writes:
>
>> On Tue, Nov 12, 2013 at 6:43 AM, Rainer Orth
>> wrote:
>>>
>>> works on Solaris 11, but not on Solaris 9 and 10 which lack
>>> TCP_KEEPALIVE_THRESHOLD.
>>
>> Do they have any facility for changing the keepalive t
On 11/15/2013 06:13 AM, Jakub Jelinek wrote:
> On Fri, Nov 15, 2013 at 05:48:27AM +1000, Richard Henderson wrote:
>> Pointers are certainly a decent fallback that would always be compatible,
>> but I wonder if we need go that far.
>>
>> Each target will have a (set of) natural simdlen to which it v
On Fri, Nov 8, 2013 at 4:01 AM, Rainer Orth
wrote:
> The recent Go patch (couldn't find the submission on gcc-patches) broke
> Solaris bootstrap: on Solaris 10/x86 I get
>
> /vol/gcc/src/hg/trunk/local/libgo/go/net/fd_select.go:90:30: error: use of
> undefined type 'pollServer'
> func (p *polls
On Fri, Nov 15, 2013 at 05:48:27AM +1000, Richard Henderson wrote:
> Pointers are certainly a decent fallback that would always be compatible,
> but I wonder if we need go that far.
>
> Each target will have a (set of) natural simdlen to which it vectorizes. This
> is the set returned by autovect
This patch to libgo fixes a flag when allocating memory from cgo. I
misunderstood the meanings of the flags. Bootstrapped and ran Go
testsuite on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 2544e5a0261f libgo/runtime/malloc.goc
--- a/libgo/runtime/malloc.goc Thu Nov 14 10:14:4
On 11/14/2013 02:30 AM, Jakub Jelinek wrote:
> As discussed earlier, if we strictly follow the Intel ABI for simds,
> we run into various issues. The clones then have to use __regcall calling
> convention which e.g. mandates that on x86_64 up to 16 vector arguments
> are passed in xmm/ymm register
Hi,
I noticed a Canadian cross failure in 4.8 which was down to BUILD_CXXFLAGS
being set to ALL_FLAGS even when build != host. Obviously this has only become
apparent with 4.8.
Thanks,
Stu
2013-11-14 Stuart Henderson
* configure (BUILD_CXXFLAGS): Set appropriately when build != hos
this is only for the whole file? I mean to have a particular loop
vectorized in a
file while all others - up to compiler's cost model. is there such a machinery?
Sergos
On Thu, Nov 14, 2013 at 12:39 PM, Richard Biener wrote:
> On Wed, 13 Nov 2013, Sergey Ostanevich wrote:
>
>> I will get some te
On Thu, Nov 14, 2013 at 10:17 AM, Andrew Pinski wrote:
> On Thu, Nov 14, 2013 at 8:25 AM, Xinliang David Li wrote:
>> Can we revisit the decision for this? Here are the reasons:
>>
>> 1) It seems that the motivation to make C++ consistent with c99 is to
>> avoid confusing users who build the C so
That extra alignment causes some branches to go out of range.
2013-11-14 Joern Rennecke
* config/arc/arc.md (doloop_begin_i): Remove extra alignment;
use (.&-4) idiom.
Index: config/arc/arc.md
===
--- config/arc/a
See the following code:
#include
using std::complex;
template
complex<_Tp>&
mult_assign (complex<_Tp>& __y, const complex<_Up>& __z)
{
_Up& _M_real = __y.real();
_Up& _M_imag = __y.imag();
const _Tp __r = _M_real * __z.real() - _M_imag * __z.imag();
_M_imag = _M_real * __z.imag() + _M_i
On 11/14/2013 11:37 AM, Paolo Carlini wrote:
+ ? TREE_TYPE (CLASSTYPE_TEMPLATE_INFO (DECL_CONTEXT (decl)))
Use CLASSTYPE_TI_TEMPLATE instead. OK with that change.
Jason
Hi!
I've committed following fix to unbreak asan on -fsection-anchors targets.
If anyone has better ideas how to represent for RTL artificial label
we emit from final.c at the beginning of current function, I'd appreciate
it.
2013-11-14 Jakub Jelinek
PR sanitizer/59122
* asan.
Hi,
On Thu, Nov 14, 2013 at 12:18:24PM +, Matthew Leach wrote:
> Martin Jambor writes:
>
> > Hi,
>
> Hi Martin,
>
> [...]
>
> >
> > 2013-11-04 Martin Jambor
> >
> > PR rtl-optimization/10474
> > * ira.c (interesting_dest_for_shprep): New function.
> > (split_liv
On Thu, Nov 14, 2013 at 8:25 AM, Xinliang David Li wrote:
> Can we revisit the decision for this? Here are the reasons:
>
> 1) It seems that the motivation to make C++ consistent with c99 is to
> avoid confusing users who build the C source with both C and C++
> compilers. Why should C++'s default
This patch expands the recent one from Dave Cheney to add all the known
gccgo architectures. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 5d4a0b7216b6 libgo/go/go/build/syslist.go
--- a/libgo/go/go/build/syslist.go Thu Nov 14 10:07:00 2013 -0
On Thu, Nov 14, 2013 at 8:51 AM, Uros Bizjak wrote:
> On Wed, Nov 13, 2013 at 6:18 PM, Uros Bizjak wrote:
>
>>> as discussed with Honza on many occasions, all users of
>>> cgraph_get_create_node really want cgraph_get_create_real_symbol_node,
>>> i.e. they are not interested in inline nodes and s
Well, if you don't change anything in omp-low.c, then it wouldn't diagnose
setjmp call in #pragma simd, but given that also the OpenMP 4.0 spec
requires that #pragma omp simd doesn't contain calls to setjmp or longjmp
(ditto for #pragma omp declare simd functions), then scan_omp_1_stmt
should be
All RX opcodes which take a dsp:8 also take a dsp:16 so we can relax
this offset check. Committed.
* config/rx/rx.c (rx_mode_dependent_address_p): Allow offsets up
to 16 bits.
Index: config/rx/rx.c
===
--- config/rx
On Thu, Nov 14, 2013 at 07:08:17PM +0100, Jakub Jelinek wrote:
> On Thu, Nov 14, 2013 at 09:56:36PM +0400, Konstantin Serebryany wrote:
> > I thought about alignment but did not reflect it anywhere in the
> > interface/comments.
> > The alignment should be min(4096, N), which is enough for most pur
On Thu, Nov 14, 2013 at 09:56:36PM +0400, Konstantin Serebryany wrote:
> I thought about alignment but did not reflect it anywhere in the
> interface/comments.
> The alignment should be min(4096, N), which is enough for most purposes.
You mean max(4096, N), right? And, what exactly is N? 1 << (c
This patch from Dave Cheney fixes the list of supported operating
systems and architectures in libgo. syslist.go used to be a generated
file in the master Go library, but it was changed a while back to a
fixed list. This patch makes the same change to libgo. Bootstrapped
and ran Go testsuite on
As part of the generalized FSA optimization work we need the ability to
start a jump threading path with a joiner, then later in the path have a
normal jump threading block (ie, has side effects and thus requires
duplication).
thread_through_normal_block needs one tweak to make that possible
On Thu, Nov 14, 2013 at 10:39:02AM -0700, Aldy Hernandez wrote:
> On 11/14/13 10:05, Jakub Jelinek wrote:
>
> [Balaji, see below for question.]
>
> >On Thu, Nov 14, 2013 at 09:49:41AM -0700, Aldy Hernandez wrote:
> >>+case OMP_PARALLEL:
> >>+case OMP_TASK:
> >>+case OMP_FOR:
> >>+
On Thu, Nov 14, 2013 at 7:33 PM, Jakub Jelinek wrote:
> On Tue, Oct 29, 2013 at 07:05:49AM -0700, Konstantin Serebryany wrote:
>> The calls are emitted by default, but the __asan_stack_malloc call is
>> done under a run-time flag
>> __asan_option_detect_stack_use_after_return.
>> So, to use the st
Diego Novillo wrote:
>On Thu, Nov 14, 2013 at 11:13 AM, Andrew MacLeod
>wrote:
>
>> very possibly, i just haven't gotten to those parts yet. I can change
>the
>> name back to gimple-decl.[ch] or some such thing if you like that
>better.
>
>As much as I hate to paint name sheds: gimple-val.[ch].
On Thu, 2013-11-14 at 00:13 -0700, Jeff Law wrote:
> On 11/08/13 12:02, David Malcolm wrote:
> >> I wouldn't mind seeing a small example proof of concept posted to help
> >> those who don't see where this is going understand the goal. I would
> >> recommend against posting another large patch for
On 11/14/13 09:57, Joseph S. Myers wrote:
Where you have
+ error ("break statement within <#pragma simd> loop body");
+ error ("continue statement within <#pragma simd> loop body");
I think you mean %< and %> (i.e. quotes) not < and >.
Indeed. Fixed.
Thank you.
On Thu, Nov 14, 2013 at 09:49:41AM -0700, Aldy Hernandez wrote:
> +case OMP_PARALLEL:
> +case OMP_TASK:
> +case OMP_FOR:
> +case OMP_SIMD:
> +case OMP_SECTIONS:
> +case OMP_SINGLE:
> +case OMP_SECTION:
> +case OMP_MASTER:
> +case OMP_ORDERED:
> +case OMP_CRIT
Where you have
+ error ("break statement within <#pragma simd> loop body");
+ error ("continue statement within <#pragma simd> loop body");
I think you mean %< and %> (i.e. quotes) not < and >.
--
Joseph S. Myers
jos...@codesourcery.com
On 11/14/2013 10:41 AM, Richard Biener wrote:
On Thu, Nov 14, 2013 at 4:10 PM, Andrew MacLeod wrote:
This patch splits out the force_gimple_operand parts of gimplify.[ch] into
their own file which will prevent the front ends from having to see
iterators, and breaks the annoying dependency cycl
David Edelsohn wrote:
>
> > To avoid having a partial ABI implementation in tree, it seems best
> > to commit this whole patch series as a single commit.
>
> > Is the series OK for mainline?
>
> The 8 patch series implementing and enabling ELFv2 is okay, including
> the implementation of command
Hi,
On 11/14/2013 03:41 PM, Jason Merrill wrote:
I don't think we need a new parameter; just pass the FIELD_DECL into
maybe_end_member_template_processing and adjust it appropriately.
Also, call m_e_m_t_p from cp_parser_late_parsing_nsdmi rather than
cp_parser_class_specifier_1.
Thanks, much
On 11/14/2013 11:23 AM, Michael Matz wrote:
Hi,
On Thu, 14 Nov 2013, Andrew MacLeod wrote:
I think if following through with the whole plan there would (and
should) be nothing remaining that could be called a gimple expression.
very possibly, i just haven't gotten to those parts yet. I can ch
Can we revisit the decision for this? Here are the reasons:
1) It seems that the motivation to make C++ consistent with c99 is to
avoid confusing users who build the C source with both C and C++
compilers. Why should C++'s default behavior be tuned for this niche
case?
2) It is very confusing for
On Thu, Nov 14, 2013 at 11:13 AM, Andrew MacLeod wrote:
> very possibly, i just haven't gotten to those parts yet. I can change the
> name back to gimple-decl.[ch] or some such thing if you like that better.
As much as I hate to paint name sheds: gimple-val.[ch].
Diego.
Hi,
On Thu, 14 Nov 2013, Andrew MacLeod wrote:
> > I think if following through with the whole plan there would (and
> > should) be nothing remaining that could be called a gimple expression.
>
> very possibly, i just haven't gotten to those parts yet. I can change
> the name back to gimple-de
On 11/14/2013 10:57 AM, Michael Matz wrote:
Hi,
On Thu, 14 Nov 2013, Andrew MacLeod wrote:
That's why I think talking about a gimple expression as if they were
somehow some stand-alone concept is fairly confusing, and introducing it
now as if it would somewhen exist would lead to going down so
Hi,
On Thu, 14 Nov 2013, Andrew MacLeod wrote:
> > That's why I think talking about a gimple expression as if they were
> > somehow some stand-alone concept is fairly confusing, and introducing it
> > now as if it would somewhen exist would lead to going down some inferior
> > design paths.
>
>
> To avoid having a partial ABI implementation in tree, it seems best
> to commit this whole patch series as a single commit.
> Is the series OK for mainline?
The 8 patch series implementing and enabling ELFv2 is okay, including
the implementation of command line switches.
There appear to be a f
On 11/14/2013 10:37 AM, Diego Novillo wrote:
On Thu, Nov 14, 2013 at 10:34 AM, Andrew MacLeod wrote:
On 11/14/2013 10:26 AM, Michael Matz wrote:
Hi,
On Wed, 13 Nov 2013, Andrew MacLeod wrote:
There needs to be a place which has gimple componentry that is not
related to or require a statemen
On Thu, Nov 14, 2013 at 4:10 PM, Andrew MacLeod wrote:
> This patch splits out the force_gimple_operand parts of gimplify.[ch] into
> their own file which will prevent the front ends from having to see
> iterators, and breaks the annoying dependency cycle between gimple.h,
> gimplify.h and gimple
On Thu, Nov 14, 2013 at 10:34 AM, Andrew MacLeod wrote:
> On 11/14/2013 10:26 AM, Michael Matz wrote:
>>
>> Hi,
>>
>> On Wed, 13 Nov 2013, Andrew MacLeod wrote:
>>
>>> There needs to be a place which has gimple componentry that is not
>>> related to or require a statement. gimple.h is becoming th
On Tue, Oct 29, 2013 at 07:05:49AM -0700, Konstantin Serebryany wrote:
> The calls are emitted by default, but the __asan_stack_malloc call is
> done under a run-time flag
> __asan_option_detect_stack_use_after_return.
> So, to use the stack-use-after-return feature you should simply
> compile with
On 11/14/2013 10:26 AM, Michael Matz wrote:
Hi,
On Wed, 13 Nov 2013, Andrew MacLeod wrote:
There needs to be a place which has gimple componentry that is not
related to or require a statement. gimple.h is becoming the home for
just 0gimple statements. There are 3 (for the moment) major class
On Thu, Nov 14, 2013 at 10:26 AM, Michael Matz wrote:
> Put another way: what do you envision that gimple expressions would be.
> For example what would you propose we could do with them?
The only expressions I have in mind are memory references and
aggregates, which can get pretty convoluted.
On Thu, Nov 14, 2013 at 11:16 AM, Bernd Edlinger
wrote:
> Hi,
>
> sorry, for the delay.
> Sandra seems to be even more busy than me...
>
> Attached is a combined patch of the original part 1, and the update,
> in diff -up format.
>
> On Mon, 11 Nov 2013 13:10:45, Richard Biener wrote:
>>
>> On Thu
Hi,
On Thu, 14 Nov 2013, Richard Biener wrote:
> Why not give bitmap_head a constructor/destructor and allow auto use of
> that. Isn't that exactly what should get 'auto' handling automagically?
auto != c++98 :-/
Ciao,
Michael.
Hi,
On Wed, 13 Nov 2013, Andrew MacLeod wrote:
> There needs to be a place which has gimple componentry that is not
> related to or require a statement. gimple.h is becoming the home for
> just 0gimple statements. There are 3 (for the moment) major classes of
> things that are in statements
On Thu, 14 Nov 2013, Jakub Jelinek wrote:
> On Wed, Nov 13, 2013 at 01:21:03PM +0100, Jakub Jelinek wrote:
> > Sergey has kindly tested the patch on SPEC2k6, but on 4 tests it revealed
> > an ICE. Here is an incremental fix for that, for now it just punts on
> > those. In theory the invariant co
Hi,
This patch follows up the problem outlined here:
http://gcc.gnu.org/ml/gcc/2013-11/msg00152.html
The patch attached prevents adding clobbers when LRA is running
in insn_invalid_p function and lra_in_progress variable is being set
just before check_rtl call. This should stop modification of i
patch2 contains the resulting include changes.
the remaining changes...
Andrew
* asan.c: Include only gimplify.h, gimplify-be.h, and/or gimple.h as
required.
* cfgloopmanip.c: Likewise.
* cgraphunit.c: Likewise.
* cilk-common.c: Likewise.
* fold-const.c: Likewise.
* function.c: Likewis
1 - 100 of 157 matches
Mail list logo