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
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
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
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
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 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
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 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 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 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 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
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 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
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 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 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
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
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
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
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
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
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 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 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 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 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
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 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
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
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
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
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, 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
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 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
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 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, 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 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
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
> > 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
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
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
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
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
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)
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
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 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 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 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 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
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/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
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
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
101 - 157 of 157 matches
Mail list logo
