On 13/03/15 11:43, Jakub Jelinek wrote:
On Fri, Mar 13, 2015 at 11:38:12AM +0100, Sebastian Huber wrote:
I would like to commit this patch to GCC 4.9 and 5.0.
libgomp/ChangeLog
2015-03-13 Sebastian Huber
* configure.tgt (*-*-rtems*): Use local-exec TLS model.
* configure.a
On Tue, Mar 31, 2015 at 09:24:30AM +0200, Sebastian Huber wrote:
>
>
> On 13/03/15 11:43, Jakub Jelinek wrote:
> >On Fri, Mar 13, 2015 at 11:38:12AM +0100, Sebastian Huber wrote:
> >>I would like to commit this patch to GCC 4.9 and 5.0.
> >>
> >>libgomp/ChangeLog
> >>2015-03-13 Sebastian Huber
Hi,
I was investigating regressions WRT to GCC 4.9 on some of Firefox talos
benchmarks. The reason turned out to be caused by wrong handling functions
that have fast inline path plus an offline slow implementation.
I.e.:
inline_caller ()
{
do_fast_job...
if (need_more_work)
no
On Mon, Mar 30, 2015 at 10:13 PM, Richard Biener wrote:
> On March 30, 2015 6:45:34 PM GMT+02:00, Alan Lawrence
> wrote:
>>-O2 was what I first used; it also occurs at -O1. -fno-tree-sra fixes
>>it.
>>
>>The problem appears to be in laying out arguments, specifically
>>varargs. From
>>the "good"
> On 03/30/2015 01:23 PM, Jan Hubicka wrote:
> >Jason probably knows better, but I think only real C++ types comply the One
> >Defintion
> >Type and should be merged. Anything we create artifically in compiler is
> >probably
> >not covered by this.
>
> Agreed, compiler internals are outside the
> OK for stage 4/stage1?
>
> Thanks,
> - Tom
> Fix bzero warning in child_setup_tty
>
> 2015-03-30 Tom de Vries
>
> PR ada/65490
> * terminals.c (child_setup_tty): Fix warning 'argument to sizeof in
> bzero call is the same expression as the destination'.
> ---
> gcc/ada/t
> > - /* ensure that s is filled with 0 */
> > - bzero (&s, sizeof (&s));
> > + /* Ensure that s is filled with 0. */
>
> Please keep the comment as is, we do not put dots on single partial sentences
> (otherwise you would have to change these everywhere, and you and I do not
> really want tha
2015-03-30 23:30 GMT+03:00 Rainer Orth :
> I originally reported the bug and did test the patch over the weekend:
> the Solaris/x86 testsuite failures are gone, so that part is fine. I
> couldn't of course test the alloca -> __builtin_alloca change since the
> tests aren't built at all.
>
> I don'
Hi Evandro
On 30/03/15 22:51, Evandro Menezes wrote:
The Samsung Exynos M1 implements the ARMv8 ISA and this patch adds support
for it through the -mcpu command-line option.
The patch was checked on arm-unknown-linux-gnueabihf without new failures.
OK for trunk?
-- Evandro Menezes Austin, TX
On 31/03/15 08:50, Richard Biener wrote:
> On Mon, Mar 30, 2015 at 10:13 PM, Richard Biener wrote:
>> On March 30, 2015 6:45:34 PM GMT+02:00, Alan Lawrence
>> wrote:
>>> -O2 was what I first used; it also occurs at -O1. -fno-tree-sra fixes
>>> it.
>>>
>>> The problem appears to be in laying out
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 Ilya Enkovich
PR driver/
Richard Biener wrote:
On Mon, Mar 30, 2015 at 10:13 PM, Richard Biener wrote:
It doesn't make sense to use the alignment of passed values. That looks like
bs.
This means that
Int I __aligned__(8);
Is passed differently than int.
Arm_function_arg needs to be fixed.
That is,
typedef int
On Tue, 31 Mar 2015, Richard Earnshaw wrote:
> On 31/03/15 08:50, Richard Biener wrote:
> > On Mon, Mar 30, 2015 at 10:13 PM, Richard Biener wrote:
> >> On March 30, 2015 6:45:34 PM GMT+02:00, Alan Lawrence
> >> wrote:
> >>> -O2 was what I first used; it also occurs at -O1. -fno-tree-sra fixes
On 31/03/15 11:00, Richard Biener wrote:
> On Tue, 31 Mar 2015, Richard Earnshaw wrote:
>
>> On 31/03/15 08:50, Richard Biener wrote:
>>> On Mon, Mar 30, 2015 at 10:13 PM, Richard Biener wrote:
On March 30, 2015 6:45:34 PM GMT+02:00, Alan Lawrence
wrote:
> -O2 was what I first use
On Tue, 31 Mar 2015, Richard Biener wrote:
> On Tue, 31 Mar 2015, Richard Earnshaw wrote:
>
> > On 31/03/15 08:50, Richard Biener wrote:
> > > On Mon, Mar 30, 2015 at 10:13 PM, Richard Biener
> > > wrote:
> > >> On March 30, 2015 6:45:34 PM GMT+02:00, Alan Lawrence
> > >> wrote:
> > >>> -O2 w
On 31/03/15 11:20, Richard Biener wrote:
> On Tue, 31 Mar 2015, Richard Biener wrote:
>
>> On Tue, 31 Mar 2015, Richard Earnshaw wrote:
>>
>>> On 31/03/15 08:50, Richard Biener wrote:
On Mon, Mar 30, 2015 at 10:13 PM, Richard Biener wrote:
> On March 30, 2015 6:45:34 PM GMT+02:00, Alan L
On Tue, Mar 31, 2015 at 11:10:39AM +0100, Richard Earnshaw wrote:
> >>> That is,
> >>>
> >>> typedef int myint __attribute__((aligned(8)));
> >>>
> >>> int main()
> >>> {
> >>> myint i = 1;
> >>> int j = 2;
> >>> __builtin_printf("%d %d\n", i, j);
> >>> }
> >>>
> >>> or
> >>>
> >>> myint i;
>
On Tue, 31 Mar 2015, Richard Earnshaw wrote:
> On 31/03/15 11:00, Richard Biener wrote:
> > On Tue, 31 Mar 2015, Richard Earnshaw wrote:
> >
> >> On 31/03/15 08:50, Richard Biener wrote:
> >>> On Mon, Mar 30, 2015 at 10:13 PM, Richard Biener
> >>> wrote:
> On March 30, 2015 6:45:34 PM GMT+
On Mon, Mar 30, 2015 at 10:38 PM, Jakub Jelinek wrote:
> On Mon, Mar 30, 2015 at 07:08:00PM -0700, H.J. Lu wrote:
>> --- a/gcc/gcc.c
>> +++ b/gcc/gcc.c
>> @@ -1566,11 +1566,13 @@ init_spec (void)
>> if (in_sep && *p == '-' && strncmp (p, "-lgcc", 5) == 0)
>> {
>> init_gcc_s
On 31/03/15 11:36, Richard Biener wrote:
> On Tue, 31 Mar 2015, Richard Earnshaw wrote:
>
>> On 31/03/15 11:00, Richard Biener wrote:
>>> On Tue, 31 Mar 2015, Richard Earnshaw wrote:
>>>
On 31/03/15 08:50, Richard Biener wrote:
> On Mon, Mar 30, 2015 at 10:13 PM, Richard Biener
> wr
On Tue, 31 Mar 2015, Richard Earnshaw wrote:
> On 31/03/15 11:20, Richard Biener wrote:
> > On Tue, 31 Mar 2015, Richard Biener wrote:
> >
> >> On Tue, 31 Mar 2015, Richard Earnshaw wrote:
> >>
> >>> On 31/03/15 08:50, Richard Biener wrote:
> On Mon, Mar 30, 2015 at 10:13 PM, Richard Biener
On Tue, 31 Mar 2015, Richard Earnshaw wrote:
> On 31/03/15 11:36, Richard Biener wrote:
> > On Tue, 31 Mar 2015, Richard Earnshaw wrote:
> >
> >> On 31/03/15 11:00, Richard Biener wrote:
> >>> On Tue, 31 Mar 2015, Richard Earnshaw wrote:
> >>>
> On 31/03/15 08:50, Richard Biener wrote:
> >>>
Richard Biener wrote:
But I find it odd that on ARM passing *((aligned_int *)p) as
vararg (only as varargs?) changes calling conventions independent
of the functions type signature.
Does it? Do you have a testcase, and compilation flags, that'll make this show
up in an RTL dump? I've tried nu
On 31/03/15 11:45, Richard Biener wrote:
> On Tue, 31 Mar 2015, Richard Earnshaw wrote:
>
>> On 31/03/15 11:36, Richard Biener wrote:
>>> On Tue, 31 Mar 2015, Richard Earnshaw wrote:
>>>
On 31/03/15 11:00, Richard Biener wrote:
> On Tue, 31 Mar 2015, Richard Earnshaw wrote:
>
>> O
On 31/03/15 11:44, Richard Biener wrote:
> On Tue, 31 Mar 2015, Richard Earnshaw wrote:
>
>> On 31/03/15 11:20, Richard Biener wrote:
>>> On Tue, 31 Mar 2015, Richard Biener wrote:
>>>
On Tue, 31 Mar 2015, Richard Earnshaw wrote:
> On 31/03/15 08:50, Richard Biener wrote:
>> On M
On Tue, 31 Mar 2015, Alan Lawrence wrote:
> Richard Biener wrote:
> >
> > But I find it odd that on ARM passing *((aligned_int *)p) as
> > vararg (only as varargs?) changes calling conventions independent
> > of the functions type signature.
>
> Does it? Do you have a testcase, and compilation f
On Tue, Mar 31, 2015 at 11:47:37AM +0100, Alan Lawrence wrote:
> Richard Biener wrote:
> >
> >But I find it odd that on ARM passing *((aligned_int *)p) as
> >vararg (only as varargs?) changes calling conventions independent
> >of the functions type signature.
>
> Does it? Do you have a testcase, a
On Tue, 31 Mar 2015, Richard Earnshaw wrote:
> On 31/03/15 11:45, Richard Biener wrote:
> > On Tue, 31 Mar 2015, Richard Earnshaw wrote:
> >
> >> On 31/03/15 11:36, Richard Biener wrote:
> >>> On Tue, 31 Mar 2015, Richard Earnshaw wrote:
> >>>
> On 31/03/15 11:00, Richard Biener wrote:
> >>>
On Tue, 31 Mar 2015, Jakub Jelinek wrote:
> On Tue, Mar 31, 2015 at 11:47:37AM +0100, Alan Lawrence wrote:
> > Richard Biener wrote:
> > >
> > >But I find it odd that on ARM passing *((aligned_int *)p) as
> > >vararg (only as varargs?) changes calling conventions independent
> > >of the functions
Hi,
This patch avoids that we try to operate on function-decl's cfun equal
to NULL within lower_emutls_function_body.
ChangeLog
2015-03-31 Kai Tietz
PR target/65566
* tree-emutls.c (lower_emutls_function_body): Don't try to
operate on node's decl function is NULL.
Ok for apply?
On Tue, Mar 31, 2015 at 01:35:56PM +0200, Kai Tietz wrote:
> Hi,
>
> This patch avoids that we try to operate on function-decl's cfun equal
> to NULL within lower_emutls_function_body.
If DECL_STRUCT_FUNCTION (node->decl) is already NULL (for which functions?),
then what is the point doing push_c
2015-03-30 20:20 GMT+03:00 Jan Hubicka :
>> On 30 Mar 14:05, Ilya Enkovich wrote:
>> > 2015-03-27 18:23 GMT+03:00 Jan Hubicka :
>> > > Index: symtab.c
>> > > ===
>> > > --- symtab.c(revision 221734)
>> > > +++ symtab.c(working
On Tue, Mar 24, 2015 at 01:14:50AM -0400, Jason Merrill wrote:
Here's my shot at this.
> The problem is that the type is considered dependent in a template but is
> not actually dependent, so we can see the exact same type outside a template
Yeah, I think this is true...
> and it's not dependen
Richard Earnshaw wrote:
On 31/03/15 11:45, Richard Biener wrote:
On Tue, 31 Mar 2015, Richard Earnshaw wrote:
On 31/03/15 11:36, Richard Biener wrote:
On Tue, 31 Mar 2015, Richard Earnshaw wrote:
On 31/03/15 11:00, Richard Biener wrote:
On Tue, 31 Mar 2015, Richard Earnshaw wrote:
On 31/
On 31/03/15 12:08, Richard Biener wrote:
> On Tue, 31 Mar 2015, Richard Earnshaw wrote:
>
>> On 31/03/15 11:45, Richard Biener wrote:
>>> On Tue, 31 Mar 2015, Richard Earnshaw wrote:
>>>
On 31/03/15 11:36, Richard Biener wrote:
> On Tue, 31 Mar 2015, Richard Earnshaw wrote:
>
>> O
The attached patch removes the special handling for nested
functions regarding the hotpatch feature on S390, i.e. nested
functions are made hotpatchable by default.
This also fixes a bug that caused part of the hotpatch prologue
being generated for nested functions. A corresponding test case
is a
2015-03-31 13:42 GMT+02:00 Jakub Jelinek :
> On Tue, Mar 31, 2015 at 01:35:56PM +0200, Kai Tietz wrote:
>> Hi,
>>
>> This patch avoids that we try to operate on function-decl's cfun equal
>> to NULL within lower_emutls_function_body.
>
> If DECL_STRUCT_FUNCTION (node->decl) is already NULL (for whi
Hi,
I had tried same approach as Marek. For me it solved the PR, but
caused other regressions on boostrap. So I dropped the way via
dependent_type_p.
Well, this bootstrap-issue might be caused by some local changes I had
forgot to remove, but I doubt it.
Marek, have you tried to do a boostrap w
2015-03-29 18:43 GMT+03:00 Jan Hubicka :
> Hi,
> this patch improve crafty performance by avoiding ipa-cp clonning of
> Search function that specializes the first iteration of the recursion.
> The patch is by Martin, I only tested it and cleaned up code in count_callers
> and set_single_call_flag
>
On Tue, Mar 31, 2015 at 02:25:14PM +0200, Kai Tietz wrote:
> Hi,
>
> I had tried same approach as Marek. For me it solved the PR, but
> caused other regressions on boostrap. So I dropped the way via
> dependent_type_p.
>
> Well, this bootstrap-issue might be caused by some local changes I had
>
On Tue, Mar 31, 2015 at 02:21:23PM +0200, Kai Tietz wrote:
> addressable used static QI file thread-local-var-1-lbv.c line 28
> col 5 align 8 context
> attributes initial
> result
> ignored SI file thread-local-var-1-lbv.c line 28 col 5 size
> unit size
> align 32 con
On Tue, Mar 31, 2015 at 02:32:32PM +0200, Marek Polacek wrote:
> On Tue, Mar 31, 2015 at 02:25:14PM +0200, Kai Tietz wrote:
> > Hi,
> >
> > I had tried same approach as Marek. For me it solved the PR, but
> > caused other regressions on boostrap. So I dropped the way via
> > dependent_type_p.
>
2015-03-31 14:34 GMT+02:00 Marek Polacek :
> On Tue, Mar 31, 2015 at 02:32:32PM +0200, Marek Polacek wrote:
>> On Tue, Mar 31, 2015 at 02:25:14PM +0200, Kai Tietz wrote:
>> > Hi,
>> >
>> > I had tried same approach as Marek. For me it solved the PR, but
>> > caused other regressions on boostrap.
On Mon, Mar 30, 2015 at 22:42:51 +0100, Julian Brown wrote:
> On Mon, 30 Mar 2015 18:42:02 +0200
> Jakub Jelinek wrote:
> > But the one Julian posted doesn't apply on top of your patch.
> > If there is any interdiff needed on top of your patch, can it be
> > posted against trunk + your patch?
>
>
On Tue, Mar 31, 2015 at 03:52:06PM +0300, Ilya Verbin wrote:
> > What is the reason to register and allocate these one at a time, rather than
> > using one struct target_mem_desc with one tgt->array for all splay tree
> > nodes registered from one image?
> > Perhaps you would just use tgt_start of
Jakub Jelinek wrote:
On Tue, Mar 31, 2015 at 11:47:37AM +0100, Alan Lawrence wrote:
Richard Biener wrote:
But I find it odd that on ARM passing *((aligned_int *)p) as
vararg (only as varargs?) changes calling conventions independent
of the functions type signature.
Does it? Do you have a testc
On Tue, 31 Mar 2015, Alan Lawrence wrote:
> Jakub Jelinek wrote:
> > On Tue, Mar 31, 2015 at 11:47:37AM +0100, Alan Lawrence wrote:
> > > Richard Biener wrote:
> > > > But I find it odd that on ARM passing *((aligned_int *)p) as
> > > > vararg (only as varargs?) changes calling conventions indepen
On 03/31/2015 03:51 AM, Jan Hubicka wrote:
Jason, please do you know what is meaning of DECL_ARTIFICIAL on class type
names? Perhaps we can drop them to 0 in free lang data?
It indicates the implicit typedef that let's you say 'S' instead of
'struct S' without writing 'typedef struct S S' your
The following avoids running into issues with the AACPS ABI on arm
when using over-aligned types on registers.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2015-03-31 Richard Biener
* tree-sra.c (create_access_replacement): Drop under-/over-alignme
On Tue, Mar 31, 2015 at 8:55 AM, Steven Bosscher wrote:
> On Sat, Mar 28, 2015 at 8:21 PM, Alexandre Oliva wrote:
>> Regstrapped on x86_64-linux-gnu native and on i686-pc-linux-gnu native
>> on x86_64, so without lto plugin. The only regression is in
>> gcc.dg/guality/pr54200.c, that explicitly d
On Tue, Mar 31, 2015 at 02:32:32PM +0200, Marek Polacek wrote:
> Of course, with --enable-languages=all. I'll re-run the bootstrap with more
> languages enabled, though.
--enable-languages=all,obj-c++,go bootstrap passed again on x86_64 and ppc64.
Marek
On 26/03/15 13:21 +, Jonathan Wakely wrote:
This includes your fix to avoid decreasing alignment, but I didn't add
a test for that as I couldn't make it fail on any of the targets I
test on.
commit f796769ad20c0353490b9f1a7e019e2f0c1771fb
Author: Jonathan Wakely
Date: Wed Sep 3 15:39:53
On Mon, Mar 30, 2015 at 9:42 PM, Bernd Edlinger
wrote:
> Hi,
>
> On Mon, 30 Mar 2015 12:33:47, Richard Biener wrote:
>>
>> So - shouldn't the check be
>>
>> if (MEM_ALIGN (op0) < GET_MODE_ALIGNMENT (fieldmode))
>> return false;
>>
>
> No. Because this example would access memory beyond the end of
*ping* on Alex' behalf and CCing the ARM maintainers.
This fix looks obvious to me, and cleans up another couple of FAILs
for the ARM port.
Richard/Ramana?
Cheers,
James
On Thu, Mar 26, 2015 at 03:28:15PM +, Alex Velenko wrote:
> On 04/03/15 11:13, Alex Velenko wrote:
> > 2015-03-04 Alex V
On Sat, Mar 28, 2015 at 8:21 PM, Alexandre Oliva wrote:
> On Mar 27, 2015, Alexandre Oliva wrote:
>
>> This patch reworks the out-of-ssa expander to enable coalescing of SSA
>> partitions that don't share the same base name. This is done only when
>> optimizing.
>
>> The test we use to tell whet
lude
-I/sw/src/fink.build/gcc5-5.0.0-1/gcc-5-20150331/libstdc++-v3/libsupc++
-I/sw/src/fink.build/gcc5-5.0.0-1/gcc-5-20150331/libstdc++-v3/include/backward
-I/sw/src/fink.build/gcc5-5.0.0-1/gcc-5-20150331/libstdc++-v3/testsuite/util
-L/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-da
On 04/03/15 11:13, Alex Velenko wrote:
> Hi,
>
> This patch fixes arm pr45701 scan assembly tests. Those test register r3 being
> used to maintain stack double word alignment. Recent optimizations reduced
> number of local variables needed in those tests, removing necessity to push
> r3.
> Testca
On 03/31/2015 06:41 AM, Jonathan Wakely wrote:
> This is the best I've come up with, does anyone have any better ideas
> than the #else branch to hardcode alignment of 16-byte types to 16?
If there's no 16 byte type, are we convinced this matters? I mean, there isn't
a 16-byte atomic instruction
On 31/03/15 07:54 -0700, Richard Henderson wrote:
On 03/31/2015 06:41 AM, Jonathan Wakely wrote:
This is the best I've come up with, does anyone have any better ideas
than the #else branch to hardcode alignment of 16-byte types to 16?
If there's no 16 byte type, are we convinced this matters?
I am fine with waiting until stage 1. When that is likely to be?
-- Caroline Tice
cmt...@google.com
On Mon, Mar 30, 2015 at 10:19 PM, Jeff Law wrote:
> On 03/27/2015 10:44 AM, Caroline Tice wrote:
>>
>> It took me a while to get a test case I'm happy with, so I'm
>> re-submitting the whole pat
On 03/31/2015 08:03 AM, Jonathan Wakely wrote:
> On 31/03/15 07:54 -0700, Richard Henderson wrote:
>> On 03/31/2015 06:41 AM, Jonathan Wakely wrote:
>>> This is the best I've come up with, does anyone have any better ideas
>>> than the #else branch to hardcode alignment of 16-byte types to 16?
>>
>
On 03/31/2015 09:12 AM, Caroline Tice wrote:
I am fine with waiting until stage 1. When that is likely to be?
We're very close (week or two) to getting the first GCC 5 RCs spun, so
stage1 for GCC 6 should open shortly thereafter.
jeff
On 31/03/15 08:13 -0700, Richard Henderson wrote:
On 03/31/2015 08:03 AM, Jonathan Wakely wrote:
On 31/03/15 07:54 -0700, Richard Henderson wrote:
On 03/31/2015 06:41 AM, Jonathan Wakely wrote:
This is the best I've come up with, does anyone have any better ideas
than the #else branch to hardc
On Tue, Mar 31, 2015 at 07:37:40AM +0300, Mikhail Maltsev wrote:
> Hi!
>
> I'm currently working on the proposed task of replacing rtx objects
> (i.e. struct rtx_def) with derived classes. I would like to get some
> feedback on this work (it's far from being finished, but basically I
> would like
On Tue, Mar 31, 2015 at 7:25 AM, Jack Howarth wrote:
> H.J.,
> While the latest patch fails to bootstrap on x86_64-apple-darwin14...
>
> _restore_x86_fp_state in os-unix-sysdep.o
> _sysdep_save_fp_ctrl_state in os-unix-sysdep.o
> ld: symbol(s) not found for architecture x86_64
> c
On Tue, Mar 31, 2015 at 15:07:58 +0200, Jakub Jelinek wrote:
> On Tue, Mar 31, 2015 at 03:52:06PM +0300, Ilya Verbin wrote:
> > > What is the reason to register and allocate these one at a time, rather
> > > than
> > > using one struct target_mem_desc with one tgt->array for all splay tree
> > > n
H.J.,
Did you attach the correct version of the patch? I don't see
anything conditional on linux.
Jack
On Tue, Mar 31, 2015 at 11:58 AM, H.J. Lu wrote:
> On Tue, Mar 31, 2015 at 7:25 AM, Jack Howarth
> wrote:
>> H.J.,
>> While the latest patch fails to bootstrap on x86_64-a
OK, thanks.
Jason
On Tue, Mar 31, 2015 at 9:09 AM, Jack Howarth wrote:
> H.J.,
> Did you attach the correct version of the patch? I don't see
> anything conditional on linux.
> Jack
My patch will build and install libgcc_nonshared.a for all targets. If you
don't link against it, nothing is changed
On Tue, Mar 31, 2015 at 12:14 PM, H.J. Lu wrote:
> On Tue, Mar 31, 2015 at 9:09 AM, Jack Howarth
> wrote:
>> H.J.,
>> Did you attach the correct version of the patch? I don't see
>> anything conditional on linux.
>> Jack
>
> My patch will build and install libgcc_nonshared.a for
On Tue, Mar 31, 2015 at 9:39 AM, Jack Howarth wrote:
> On Tue, Mar 31, 2015 at 12:14 PM, H.J. Lu wrote:
>> On Tue, Mar 31, 2015 at 9:09 AM, Jack Howarth
>> wrote:
>>> H.J.,
>>> Did you attach the correct version of the patch? I don't see
>>> anything conditional on linux.
>>> Ja
Hello!
As shown in the PR, the attached patch substantial improves generated
code when cmpxchg}8,16}b insn is involved. Following testcase:
--cut here--
__int128_t i;
int main()
{
__atomic_store_16(&i, -1, 0);
if (i != -1)
__builtin_abort();
return 0;
}
--cut here--
compiles with -O2
Hi,
thus, in order to not warn -Wshadow at instantiation time, I figured out
the below. Tested x86_64-linux.
Note, I took the idea of allowing for current_instantiation ()->decl !=
current_function_decl from some code prepared by Dodji for
-Wunused-local-typedefs: I'm not 100% sure it's nece
On 03/29/2015 09:25 AM, Steve Kargl wrote:
On Sat, Mar 28, 2015 at 01:01:57AM +0100, Dominique Dhumieres wrote:
AFAICT your test succeeds without your patch and does not test that the ICE
reported by FX is gone (indeed it is with your patch).
New patch and testcase. The ChangeLog entries ar
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
requires it be a template with a pointer field followed by an integer field,
and in this case it is, but convert_like_real
When a complex package has both external and internal tests, we need
to link against the external tests first. This patch from Dave Cheney
fixes this. Bootstrapped on x86_64-unknown-linux-gnu. Committed to
mainline.
Ian
diff -r c601118c5169 libgo/go/cmd/go/build.go
--- a/libgo/go/cmd/go/build.g
Hi,
David correctly pointed out offline that I used the wrong macro to test
for efficient unaligned access. Here's a corrected version, which still
fixes PR65456 without causing regressions. Sorry for the error!
Thanks,
Bill
On Sun, 2015-03-29 at 12:42 -0500, Bill Schmidt wrote:
> Hi,
>
> Thi
On Mon, Mar 30, 2015 at 18:42:02 +0200, Jakub Jelinek wrote:
> Shouldn't either this function, or gomp_offload_image_to_device lock
> also devicep->lock mutex and unlock at the end?
> Where exactly I guess depends on if the devicep->* hook calls should be
> guarded with the mutex or not. If yes, i
On Tue, Mar 31, 2015 at 1:00 PM, H.J. Lu wrote:
> On Tue, Mar 31, 2015 at 9:39 AM, Jack Howarth
> wrote:
>> On Tue, Mar 31, 2015 at 12:14 PM, H.J. Lu wrote:
>>> On Tue, Mar 31, 2015 at 9:09 AM, Jack Howarth
>>> wrote:
H.J.,
Did you attach the correct version of the patch? I don'
On Tue, Mar 31, 2015 at 09:25:26PM +0300, Ilya Verbin wrote:
> On Mon, Mar 30, 2015 at 18:42:02 +0200, Jakub Jelinek wrote:
> > Shouldn't either this function, or gomp_offload_image_to_device lock
> > also devicep->lock mutex and unlock at the end?
> > Where exactly I guess depends on if the device
On 31/03/15 15:30, Richard Earnshaw wrote:
On 04/03/15 11:13, Alex Velenko wrote:
Hi,
This patch fixes arm pr45701 scan assembly tests. Those test register r3 being
used to maintain stack double word alignment. Recent optimizations reduced
number of local variables needed in those tests, remo
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
requires it be a template with a pointer field followed by an integer field,
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.
Jason
I noticed that I accidentally committed three generated files in
libgo/runtime. They are unused. I committed this patch to remove
them.
Ian
Index: libgo/runtime/chan.c
===
--- libgo/runtime/chan.c(revision 221440)
+++ libgo/
On Tue, Mar 31, 2015 at 11:55 AM, H.J. Lu wrote:
> On Tue, Mar 31, 2015 at 10:18 AM, Antoine Tremblay
> wrote:
>>
>>
>> On 03/31/2015 01:16 PM, H.J. Lu wrote:
>>>
>>> On Tue, Mar 31, 2015 at 10:12 AM, Antoine Tremblay
>>> wrote:
>
> Also doing ./configure in binutils/zlib I get :
>
>
On Tue, Mar 31, 2015 at 2:00 PM, Bill Schmidt
wrote:
> Hi,
>
> David correctly pointed out offline that I used the wrong macro to test
> for efficient unaligned access. Here's a corrected version, which still
> fixes PR65456 without causing regressions. Sorry for the error!
>
> Thanks,
> Bill
>
On Tue, Mar 31, 2015 at 19:10:36 +0300, Ilya Verbin wrote:
> Ok, thanks for the clarification! Here is the new patch with variables.
>
> Unfortunately I see 4 fails in make check-target-libgomp with PTX patch
> applied
> on top, but with disabled offloading to PTX.
> Julian, have you seen them?
Hi, Kyrill.
At this moment, it suffices to use the same scheduling as Cortex A57, but
more specific details are to be expected.
I couldn't check the build though, as my Arndale is strange today. As soon
as it's healthy, I'll check it.
I appreciate your feedback.
--
Evandro Menezes
Hi, Evandro.
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org
> [mailto:gcc-patches-ow...@gcc.gnu.org]
> On Behalf Of Evandro Menezes
> Sent: Tuesday, March 31, 2015 6:51 AM
> To: 'GCC Patches'
> Subject: [PATCH] [AArch64] Add support for the Samsung Exynos M1
> processor
>
>
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;
> +
> + for (i = 0; i < num_devices; i++)
> +gomp_mutex_unlock (&devices[
Hi,
this patch solves ICE in the attached testcase on mingw32. The problem is that
on Windows API long double is passed & returned by reference and while expanidng
the tunk tail call, we get lost because we turn the parameter into SSA name and
later need its address to pass it further.
The patch
91 matches
Mail list logo
