On Thu, Nov 14, 2013 at 10:09 PM, Jakub Jelinek wrote:
> 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
> 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.
Well, it's equivalent to knowingly breaking it further when you're making
systemic changes like these... A quick search with bugzilla would have
Hi Jakub,
Here is a patch for generation of tables containing omp-functions addresses.
It is just a first step, as it lacks generation of similar tables for globals,
but having it in the branch would ease our further development, as we would be
able to base on this.
This patch introduces new func
On Thu, 14 Nov 2013, Cong Hou wrote:
> 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 suc
On Fri, Nov 15, 2013 at 4:54 AM, Sriraman Tallam wrote:
> Currently on trunk the option -mpreferred-stack-boundary does not work
> together with #pragma GCC target("sse") or
> __attribute__((target("sse"))).
>
> There is already a test case that detects th
Hello!
> 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
Martin Jambor writes:
> 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_shp
On Thu, Nov 14, 2013 at 7:16 PM, Uros Bizjak wrote:
> 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_n
Hi,
On Thu, 14 Nov 2013 16:31:10, Richard Biener wrote:
>
> 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
Hello!
> 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 should get a
> standalone node instead. So this patch changes cgraph_get_create_node
> t
On Thu, Nov 14, 2013 at 9:58 PM, Jeff Law wrote:
>
> 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 c
> Hi,
> this patch makes it possible to access value range info from setmem/movstr
> that
> I plan to use in i386 memcpy/memset expansion code. It is all quite
> straighforward except that I need to deal with cases where max size does not
> fit in HOST_WIDE_INT where I use maximal value as a mark
On Thu, Nov 14, 2013 at 10:04 PM, Richard Sandiford
wrote:
> 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_
> diff --git a/gcc/config/ia64/ia64.c b/gcc/config/ia64/ia64.c
> index a128b19..446ee59 100644
> --- a/gcc/config/ia64/ia64.c
> +++ b/gcc/config/ia64/ia64.c
> @@ -1527,12 +1527,19 @@ ia64_split_tmode_move (rtx operands[])
>&& reg_overlap_mentioned_p (operands[0], operands[1]))
> {
>
On Fri, Nov 15, 2013 at 12:46 AM, Jan Hubicka wrote:
>> > 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 -
On Thu, Nov 14, 2013 at 10:33 PM, 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 put
On Fri, 15 Nov 2013 10:09:02, Uros Bizjak wrote:
>
> On Fri, Nov 15, 2013 at 4:54 AM, Sriraman Tallam wrote:
>
>> Currently on trunk the option -mpreferred-stack-boundary does not
>> work
>> together with #pragma GCC target("sse") or
>> __attribute__((target("sse"
On Fri, Nov 15, 2013 at 3:49 AM, Andrew MacLeod wrote:
> 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 l
> On Fri, Nov 15, 2013 at 12:46 AM, Jan Hubicka wrote:
> >> > 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
> >> > te
On Fri, Nov 15, 2013 at 11:02 AM, Jan Hubicka wrote:
>> >> > * 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].
>> >> >
>>
On Fri, Nov 15, 2013 at 10:58 AM, Bernd Edlinger
wrote:
Well, this way it could be fixed too.
But opts->x_ix86_preferred_stack_bounary_arg is not dependent on any
pragma or target attribute. Correct me if that is wrong.
>>>
>>> That seems correct.
>>>
And this code
>
On Fri, Nov 15, 2013 at 12:06:25PM +0400, Konstantin Serebryany wrote:
> On Thu, Nov 14, 2013 at 10:09 PM, Jakub Jelinek wrote:
> > 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 alig
> This is what I got. I added s-posix-time.ads which declares
> System.OS_Time.time_t. I use it instead long for time_t. I
> didn't add time_t to s-linux.ads since it isn't used by
> s-osprim-posix.adb.
Adding s-posix-time.ads isn't desirable, too intrusive.
Better to use time_t (only) from sys
On Thu, Oct 31, 2013 at 11:27 AM, Bernd Edlinger
wrote:
> Hello,
>
> meanwhile, I have added a test case to that patch.
>
> Boot-strapped and regression-tested as usual.
>
> OK for trunk?
Err, well. This just means that the generic C++ memory model
handling isn't complete. We do
if (TREE
On Fri, Nov 15, 2013 at 11:12:39AM +0100, Richard Biener wrote:
> Btw, what does the C++ memory model say for
>
> struct { char x; short a; short b; } a __attribute__((packed));
Nothing, because packed is outside of the standard?
Jakub
On Fri, Nov 15, 2013 at 10:28 AM, Bernd Edlinger
wrote:
> Hi,
>
> On Thu, 14 Nov 2013 16:31:10, Richard Biener wrote:
>>
>> 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 combi
On Fri, 15 Nov 2013, Jan Hubicka wrote:
> > Hi,
> > this patch makes it possible to access value range info from setmem/movstr
> > that
> > I plan to use in i386 memcpy/memset expansion code. It is all quite
> > straighforward except that I need to deal with cases where max size does not
> > fit
On Fri, Nov 15, 2013 at 11:14 AM, Jakub Jelinek wrote:
> On Fri, Nov 15, 2013 at 11:12:39AM +0100, Richard Biener wrote:
>> Btw, what does the C++ memory model say for
>>
>> struct { char x; short a; short b; } a __attribute__((packed));
>
> Nothing, because packed is outside of the standard?
Ok,
On Fri, Nov 15, 2013 at 10:56:24AM +0100, Richard Biener wrote:
> On Thu, Nov 14, 2013 at 10:33 PM, 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 chang
Hello,
> I suspect that the problem reported by Jeff is related to the usage of "dead"
> in the REG subcase of the MEM case of ia64_split_tmode. There is a dangling
> comment to that effect in ia64_split_tmode_move just above the block.
We're failing here. Trying to split SET with these operand
On Fri, Nov 15, 2013 at 2:11 AM, Arnaud Charlet wrote:
>> This is what I got. I added s-posix-time.ads which declares
>> System.OS_Time.time_t. I use it instead long for time_t. I
>> didn't add time_t to s-linux.ads since it isn't used by
>> s-osprim-posix.adb.
>
> Adding s-posix-time.ads isn't
Richard Biener writes:
> On Thu, Nov 14, 2013 at 10:04 PM, Richard Sandiford
> wrote:
>> 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 r
> >> This is what I got. I added s-posix-time.ads which declares
> >> System.OS_Time.time_t. I use it instead long for time_t. I
> >> didn't add time_t to s-linux.ads since it isn't used by
> >> s-osprim-posix.adb.
> >
> > Adding s-posix-time.ads isn't desirable, too intrusive.
> > Better to use
On Fri, Nov 15, 2013 at 2:50 AM, Arnaud Charlet wrote:
>> >> This is what I got. I added s-posix-time.ads which declares
>> >> System.OS_Time.time_t. I use it instead long for time_t. I
>> >> didn't add time_t to s-linux.ads since it isn't used by
>> >> s-osprim-posix.adb.
>> >
>> > Adding s-po
Tested on x86_64-suse-linux, applied on the mainline as obvious.
2013-11-15 Eric Botcazou
* fold-const.c (fold_binary_loc) : Reuse local variable.
--
Eric BotcazouIndex: fold-const.c
===
--- fold-const.c (revision 2048
On Fri, Nov 15, 2013 at 11:48 AM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Thu, Nov 14, 2013 at 10:04 PM, Richard Sandiford
>> wrote:
>>> 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 t
Il 06/11/2013 19:33, Joseph S. Myers ha scritto:
> +dnl GCC_GLIBC_VERSION_GTE_IFELSE(MAJOR, MINOR, IF-TRUE, IF-FALSE)
> +dnl -
> +dnl If the target glibc version ($glibc_version_major.$glibc_version_minor)
> +dnl is at least MAJOR.MINOR, c
Il 14/11/2013 15:08, Rainer Orth ha scritto:
> libcilkrts.so fails to link on Solaris 9/x86 with Sun as since this
> configuration lacks visibility support:
>
> Text relocation remains referenced
> against symbol offset in file
> __cilkrts_get_tls_
Il 13/11/2013 15:06, Rainer Orth ha scritto:
>
> This happens because there's no installed amd64 libgcc_s.so.1 on the
> system, and toplevel Makefile only sets LD_LIBRARY_PATH for the default
> multilib. Initially, I thought that there were something special going
> on, but it turned out that oth
On Fri, Nov 15, 2013 at 11:37 AM, Trevor Saunders wrote:
> On Fri, Nov 15, 2013 at 10:56:24AM +0100, Richard Biener wrote:
>> On Thu, Nov 14, 2013 at 10:33 PM, Jeff Law wrote:
>> > On 11/14/13 14:14, Richard Biener wrote:
>> >>>
>> >>>
>> >>> I'm just pointed out that of all the stuff you changed
Looks better now, but please do not add a dependency on System.Linux in
s-taprop-linux.adb, and instead use:
type timeval is array (1 .. 2) of System.OS_Interface.time_t;
Arno
Hi,
because the compiler still uses the legacy encodings for the VFP registers in
DWARF, when for example d8 is saved onto the stack, the CFI records a save of
s16. This is more or less correct in little-endian mode, but plain wrong in
big-endian mode where s17 is saved first at that address.
On Fri, Nov 15, 2013 at 3:18 AM, Arnaud Charlet wrote:
> Looks better now, but please do not add a dependency on System.Linux in
> s-taprop-linux.adb, and instead use:
>
> type timeval is array (1 .. 2) of System.OS_Interface.time_t;
>
> Arno
It doesn't work:
s-taprop.adb:630:60: "time_t" is
> > Looks better now, but please do not add a dependency on System.Linux in
> > s-taprop-linux.adb, and instead use:
> >
> > type timeval is array (1 .. 2) of System.OS_Interface.time_t;
> >
> > Arno
>
> It doesn't work:
>
> s-taprop.adb:630:60: "time_t" is not a visible entity of "OS_Interfa
On Fri, Nov 15, 2013 at 3:52 AM, Ian Lance Taylor 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 1
>
> This one is new, I have to look
> We're failing here. Trying to split SET with these operands:
> operands[0] is (reg:TI 14 r14 [orig:448 *_61[_12]{lb: 1 sz: 64}.text ]
> [448]) operands[1] is (mem:TI (reg/f:DI 15 r15 [447]) [3 *_61[_12]{lb: 1
> sz: 64}.text+0 S16 A128])
>
> I think that such a set (despite of intersect by
>
> Err, well. This just means that the generic C++ memory model
> handling isn't complete. We do
>
> if (TREE_CODE (to) == COMPONENT_REF
> && DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1)))
> get_bit_range (&bitregion_start, &bitregion_end, to, &bitpos, &offset);
>
> and thus restrict ourselves to bit
On Fri, Nov 15, 2013 at 3:38 AM, Arnaud Charlet wrote:
>> > Looks better now, but please do not add a dependency on System.Linux in
>> > s-taprop-linux.adb, and instead use:
>> >
>> > type timeval is array (1 .. 2) of System.OS_Interface.time_t;
>> >
>> > Arno
>>
>> It doesn't work:
>>
>> s-ta
On Mon, Nov 11, 2013 at 5:13 PM, Trevor Saunders wrote:
> On Mon, Nov 11, 2013 at 12:58:36PM +0100, Richard Biener wrote:
>> On Mon, Nov 11, 2013 at 1:39 AM, Trevor Saunders
>> wrote:
>> > On Fri, Nov 08, 2013 at 10:37:00AM +0100, Richard Biener wrote:
>> >> On Thu, Nov 7, 2013 at 5:00 PM, wro
> Here is the new patch. Does it look OK?
Assuming you can successfully build on e.g. x86-linux and x32-linux, this
looks OK to me, thanks for your efforts!
Arno
>>
>> hmm...
>> the above change is just not aggressive enough.
>>
>>
>> with a slightly changed test case I have now got a
>> recursion on the extract_fixed_bit_fields on ARM but
>> interestingly not on powerpc:
>>
>> #include
>>
>> typedef struct {
>> char pad;
>> int arr[0];
>> } __attribute__(
On Fri, Nov 15, 2013 at 3:56 AM, Arnaud Charlet wrote:
>> Here is the new patch. Does it look OK?
>
> Assuming you can successfully build on e.g. x86-linux and x32-linux, this
> looks OK to me, thanks for your efforts!
>
Yes, it passed all tests with -m32, -mx32, -m64 on Linux/x86-64.
Installed
On Fri, Nov 15, 2013 at 12:54:05PM +0100, Richard Biener wrote:
> On Mon, Nov 11, 2013 at 5:13 PM, Trevor Saunders
> wrote:
> > On Mon, Nov 11, 2013 at 12:58:36PM +0100, Richard Biener wrote:
> >> On Mon, Nov 11, 2013 at 1:39 AM, Trevor Saunders
> >> wrote:
> >> > On Fri, Nov 08, 2013 at 10:37:
On Fri, Nov 15, 2013 at 1:11 PM, Trevor Saunders wrote:
> On Fri, Nov 15, 2013 at 12:54:05PM +0100, Richard Biener wrote:
>> On Mon, Nov 11, 2013 at 5:13 PM, Trevor Saunders
>> wrote:
>> > On Mon, Nov 11, 2013 at 12:58:36PM +0100, Richard Biener wrote:
>> >> On Mon, Nov 11, 2013 at 1:39 AM, Trev
On Fri, Nov 15, 2013 at 2:23 AM, Jeff Law wrote:
> On 11/14/13 15:19, Diego Novillo wrote:
>>
>> A good chunk. I'm doing these FIXMEs in the next sequence of patches,
>> so we won't have them for long. Again, I was going for an orderly
>> transition here.
>
> However, I'm much more concerned abou
On Fri, Nov 15, 2013 at 12:38 PM, Bernd Edlinger
wrote:
>>
>> Err, well. This just means that the generic C++ memory model
>> handling isn't complete. We do
>>
>> if (TREE_CODE (to) == COMPONENT_REF
>> && DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1)))
>> get_bit_range (&bitregion_start, &bitregion_en
On Fri, Nov 15, 2013 at 1:08 PM, Bernd Edlinger
wrote:
>>>
>>> hmm...
>>> the above change is just not aggressive enough.
>>>
>>>
>>> with a slightly changed test case I have now got a
>>> recursion on the extract_fixed_bit_fields on ARM but
>>> interestingly not on powerpc:
>>>
>>> #include
>>>
> Are there any other restrictions? Do they, for example, guarantee to
> restore all call-saved registers to their values at the time of the
> __builtin_longjmp call, including those for which libc's setjmp and
> longjmp need to test for existence at runtime (but they may have been used
> in an in
On Fri, Nov 15, 2013 at 12:35 PM, 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 1
>>
>> This one is new, I have to lo
On Fri, Nov 15, 2013 at 12:35 PM, 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 1
>>
>> This one is new, I have to lo
points-to analysis is currently not able to disambiguate global
memory as-of function activation (aka 'nonlocal') against memory
that is allocated inside the function. This is because we glob
them together to make users of ptr_deref_may_alias_global_p
happy (an odd function which asks whether a s
Hi all,
For IBM long double, adding a normal number to a qNaN raises an inexact
exception. Adding any number to qNaN should not raise any exception. The
following testcase triggers the issue (the testcase is meant to run a gnu
compatible libc):
-
On Fri, Nov 15, 2013 at 12:11:07PM +0100, Richard Biener wrote:
> On Fri, Nov 15, 2013 at 11:37 AM, Trevor Saunders
> wrote:
> > On Fri, Nov 15, 2013 at 10:56:24AM +0100, Richard Biener wrote:
> >> On Thu, Nov 14, 2013 at 10:33 PM, Jeff Law wrote:
> >> > On 11/14/13 14:14, Richard Biener wrote:
On Thu, Nov 14, 2013 at 9:49 PM, Andrew MacLeod wrote:
> 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 l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The patch is the same as before (but for newer revision 204343 so line
numbers are a bit different), but the copyright assignment has been
sorted out and the changelog has been modified as discussed by Dodji
Seketeli. I think it is ready to be applied
On Thu, 14 Nov 2013, Andrew MacLeod wrote:
> 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 "Inc
Hi,
Here is a patch to introduce builtin to bind bounds for call arguments as was
discussed here (http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00872.html).
Patch also removes outdated gimple ifaces.
Thanks,
Ilya
--
2013-11-15 Ilya Enkovich
* builtin-types.def (BT_FN_PTR_CONST_PTR_V
>
> But then why is the mode QImode in the first place? The access is
> definitely of SImode.
>
that's in the test case:
s->arr[0] = 0x12345678;
it is QImode from that in expand_assignment:
to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);
tem is "s", a MEM_REF, of QImode,
On 11/15/2013 05:01 AM, Richard Biener wrote:
On Fri, Nov 15, 2013 at 3:49 AM, Andrew MacLeod wrote:
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/msg0166
On Fri, 15 Nov 2013, Richard Biener wrote:
> Yeah, though this has interesting effects on includes that do stuff like
>
> #ifdef NO_DOLLARS_IN_LABELS
> ...
>
> where the presence of this definition depends on another header file
> and thus the ultimate outcome in your .c file depends on include
On 11/15/2013 08:16 AM, Joseph S. Myers wrote:
On Thu, 14 Nov 2013, Andrew MacLeod wrote:
btw, I ran tm.h through the include removal script for the c family front end
files... The attached patch compiles on x64 and removes 37 includes from the
front end files those are just the extraneous
On Fri, Nov 15, 2013 at 12:35:12PM +0400, Michael V. Zolotukhin wrote:
> 2013-11-15 Michael Zolotukhin
>
> * omp-low.c (omp_finish_file): New.
> * omp-low.h (omp_finish_file): Declare new function.
> * toplev.c: include "omp-low.h"
That would be
* toplev.c: Include o
On 11/15/2013 08:31 AM, Joseph S. Myers wrote:
On Fri, 15 Nov 2013, Richard Biener wrote:
Yeah, though this has interesting effects on includes that do stuff like
#ifdef NO_DOLLARS_IN_LABELS
...
where the presence of this definition depends on another header file
and thus the ultimate outcome
On Wed Nov 13 07:53:25 2013, Jeff Law wrote:
> I'll have a patch going through testing overnight.
If you have a patch, could you post it please?
TIA
Dominique
> Yes, it passed all tests with -m32, -mx32, -m64 on Linux/x86-64.
> Installed on trunk. Is this OK to backport to 4.8 branch after
> a few days?
I would wait one or two weeks, to let time for people to report build
failures on other configs which is always possible when doing this kind of
delicat
Now that there is (finally :() a wrong-code testcase for the
PR54570 issue we can no longer ignore it (bah). So the following
tries to paper over the fact that object-size sucks and disables
value-numbering of equal addresses the same before that pass
had a chance to finally look at the structure
Hello,
On 15 Nov 12:34, Eric Botcazou wrote:
> > (insn 199 0 0 (set (reg:DI 14 r14)
> > (mem:DI (post_inc:DI (reg/f:DI 15 r15 [447])) [3
> > *_61[_12]{lb: 1 sz: 64}.text+0 S8 A128])) -1 (nil))
> > (insn 200 199 0 (set (reg:DI 15 r15)
> > (mem:DI (post_dec:DI (reg/f
Hi!
Here is an implementation of init-order checking (at least how I understand
it from looking at libsanitizer and eyeballing what clang emits) plus some
performance improvements.
Previously instrument_derefs ignored stores and loads from VAR_DECLs, that
is of course now not possible generally,
> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Friday, November 15, 2013 2:38 AM
> To: Aldy Hernandez
> Cc: Jason Merrill; gcc-patches; Iyer, Balaji V
> Subject: Re: PING: Fwd: Re: [patch] implement Cilk Plus simd loops on trunk
>
> On Thu, Nov 14, 2013 at 0
Richard,
here's an example that causes trigger for the cost model. As soon as
elemental functions will appear and we update the vectorizer so it can accept
an elemental function inside the loop - we will have the same
situation as we have
it now: cost model will bail out with profitability estimat
On Fri, Nov 15, 2013 at 2:19 PM, Ilya Enkovich wrote:
> Hi,
>
> Here is a patch to introduce builtin to bind bounds for call arguments as was
> discussed here (http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00872.html).
> Patch also removes outdated gimple ifaces.
Looks good to me in principle b
On Fri, Nov 15, 2013 at 02:56:51PM +0100, Richard Biener wrote:
> Now that there is (finally :() a wrong-code testcase for the
> PR54570 issue we can no longer ignore it (bah). So the following
> tries to paper over the fact that object-size sucks and disables
> value-numbering of equal addresses
On Fri, Nov 15, 2013 at 2:24 PM, Bernd Edlinger
wrote:
>>
>> But then why is the mode QImode in the first place? The access is
>> definitely of SImode.
>>
>
> that's in the test case:
>
> s->arr[0] = 0x12345678;
>
>
> it is QImode from that in expand_assignment:
>
> to_rtx = expand_expr (t
On 11/15/13 06:47, Dominique Dhumieres wrote:
On Wed Nov 13 07:53:25 2013, Jeff Law wrote:
I'll have a patch going through testing overnight.
If you have a patch, could you post it please?
It's checked into the trunk. Ada, at least on x86_64 should be
functional again.
jeff
On 15 Nov 16:55, Kirill Yukhin wrote:
> Bootstrap (with Ada) is still in progress.
Passed for me (seems here is no Jeff's patch)
> > I guess it depends on what the Cilk+ spec says about reduction clause, and
> > from what I saw it is just too vague.
> > http://software.intel.com/sites/products/documentation/doclib/stdxe/2013
> > /composerxe/compiler/cpp-win/index.htm#GUID-44B505B6-01AF-4865-
> > 8DF4-AF851F51DDA1.htm
>
> Ju
On Fri, Nov 15, 2013 at 2:10 PM, Jakub Jelinek wrote:
> On Fri, Nov 15, 2013 at 12:06:25PM +0400, Konstantin Serebryany wrote:
>> On Thu, Nov 14, 2013 at 10:09 PM, Jakub Jelinek wrote:
>> > On Thu, Nov 14, 2013 at 07:08:17PM +0100, Jakub Jelinek wrote:
>> >> On Thu, Nov 14, 2013 at 09:56:36PM +04
2013/11/15 Richard Biener :
> On Fri, Nov 15, 2013 at 2:19 PM, Ilya Enkovich wrote:
>> Hi,
>>
>> Here is a patch to introduce builtin to bind bounds for call arguments as
>> was discussed here
>> (http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00872.html). Patch also
>> removes outdated gimple i
On Fri, Nov 15, 2013 at 2:39 PM, Andrew MacLeod wrote:
> On 11/15/2013 08:31 AM, Joseph S. Myers wrote:
>>
>> On Fri, 15 Nov 2013, Richard Biener wrote:
>>
>>> Yeah, though this has interesting effects on includes that do stuff like
>>>
>>> #ifdef NO_DOLLARS_IN_LABELS
>>> ...
>>>
>>> where the pre
On Wed, 2013-11-13 at 11:25 -0600, Peter Bergner wrote:
> On Wed, 2013-11-13 at 00:49 +0100, Jakub Jelinek wrote:
> > 2013-11-12 Jakub Jelinek
> >
> > * sanitizer_common/sanitizer_platform_limits_linux.cc: Temporarily
> > ifdef out almost the whole source.
> > * sanitizer_common/san
Hi,
I'm agree. I looked at the ARM backend and it occurs that the usage
of optimize_insn_for_size_p() was added to only use store_minmax in
cold path because of some performance issue. But in any case its
usage doesn't shrink the number of instruction, if we are in ARM mode
3 are needed : 1 comp
On Fri, Nov 15, 2013 at 06:06:24PM +0400, Sergey Ostanevich wrote:
> here's an example that causes trigger for the cost model. As soon as
> elemental functions will appear and we update the vectorizer so it can accept
> an elemental function inside the loop - we will have the same
> situation as we
On 15/11/13 14:19, Yvan Roux wrote:
> Hi,
>
> I'm agree. I looked at the ARM backend and it occurs that the usage
> of optimize_insn_for_size_p() was added to only use store_minmax in
> cold path because of some performance issue. But in any case its
> usage doesn't shrink the number of instruct
On Fri, 15 Nov 2013, Sergey Ostanevich wrote:
> Richard,
>
> here's an example that causes trigger for the cost model.
I hardly believe that (AVX2)
.L9:
vmovups (%rsi), %xmm3
addl$1, %r8d
addq$256, %rsi
vinsertf128 $0x1, -240(%rsi), %ymm3, %ymm1
David Edelsohn wrote:
> 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 sug
On Fri, 15 Nov 2013, Jakub Jelinek wrote:
> On Fri, Nov 15, 2013 at 02:56:51PM +0100, Richard Biener wrote:
> > Now that there is (finally :() a wrong-code testcase for the
> > PR54570 issue we can no longer ignore it (bah). So the following
> > tries to paper over the fact that object-size sucks
On Fri, Nov 15, 2013 at 3:12 PM, Ilya Enkovich wrote:
> 2013/11/15 Richard Biener :
>> On Fri, Nov 15, 2013 at 2:19 PM, Ilya Enkovich
>> wrote:
>>> Hi,
>>>
>>> Here is a patch to introduce builtin to bind bounds for call arguments as
>>> was discussed here
>>> (http://gcc.gnu.org/ml/gcc-patche
On Fri, Nov 15, 2013 at 06:12:07PM +0400, Konstantin Serebryany wrote:
> I afraid it actually wants the header (magic, descr, pc) to be in the
> first 3 words in the
> memory returned by __asan_stack_malloc_*
> FakeStack::AddrIsInFakeStack(addr) returns the beginning of the allocated
> chunk
> and
On 15 Nov 18:12, Ilya Enkovich wrote:
> 2013/11/15 Richard Biener :
> > On Fri, Nov 15, 2013 at 2:19 PM, Ilya Enkovich
> > wrote:
> >> Hi,
> >>
> >> Here is a patch to introduce builtin to bind bounds for call arguments as
> >> was discussed here
> >> (http://gcc.gnu.org/ml/gcc-patches/2013-11/
On Fri, Nov 15, 2013 at 3:34 PM, Ilya Enkovich wrote:
> On 15 Nov 18:12, Ilya Enkovich wrote:
>> 2013/11/15 Richard Biener :
>> > On Fri, Nov 15, 2013 at 2:19 PM, Ilya Enkovich
>> > wrote:
>> >> Hi,
>> >>
>> >> Here is a patch to introduce builtin to bind bounds for call arguments as
>> >> was
1 - 100 of 191 matches
Mail list logo
