Dear Andre,
As far as I can see, the problems with PR57117 are specific to RESHAPE
and need not affect committing your patch. To my surprise, the
combination of your patch and mine for PR67171 fixes PR67044 in that
the ICE no longer occurs. I have to get my head around how to write a
testcase for
On 23 October 2015 at 16:20, Alan Lawrence wrote:
> diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-7.c
> b/gcc/testsuite/gcc.dg/vect/bb-slp-7.c
> index ab54a48..b012d78 100644
> --- a/gcc/testsuite/gcc.dg/vect/bb-slp-7.c
> +++ b/gcc/testsuite/gcc.dg/vect/bb-slp-7.c
> @@ -16,12 +16,12 @@ main1 (uns
On Sun, Oct 25, 2015 at 7:51 PM, Alan Lawrence wrote:
> On 23 October 2015 at 16:20, Alan Lawrence wrote:
>> diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-7.c
>> b/gcc/testsuite/gcc.dg/vect/bb-slp-7.c
>> index ab54a48..b012d78 100644
>> --- a/gcc/testsuite/gcc.dg/vect/bb-slp-7.c
>> +++ b/gcc/tes
Hi Paul, hi all,
thanks for the review. Submitted as r229294.
Regards,
Andre
On Sun, 25 Oct 2015 08:43:24 +0100
Paul Richard Thomas wrote:
> Dear Andre,
>
> As far as I can see, the problems with PR57117 are specific to RESHAPE
> and need not affect committing your patch. To my surpri
> Le 24 oct. 2015 à 21:08, Dominique d'Humières a écrit :
>
>
>> Le 24 oct. 2015 à 15:46, Dominique d'Humières a écrit :
>>
>> Dear Paul,
>>
>> AFAICT no patch!
>>
>> Dominique
>>
>
> If I am not mistaken, your patch fixes pr67528 also.
Confirmed with a clean trunk with your patch. It al
> It also fixes the ICEs in pr61829 and pr61830.
I meant pr61829 and not pr61829.
Dominique
Hello!
Inverted condition is generated with =@ccae.
2015-10-25 Uros Bizjak
PR target/68084
* config/i386/i386.c (ix86_md_asm_adjust) [case 'a']: Use NE code
for =@ccae.
testsuite/ChangeLog:
2015-10-25 Uros Bizjak
PR target/68084
* gcc.target/i386/pr68084.c: New test.
> Le 25 oct. 2015 à 14:13, Dominique d'Humières a écrit :
>
>> It also fixes the ICEs in pr61829 and pr61830.
>
> I meant pr61829 and not pr61829.
Please read pr61819 and pr61830. Sorry for the noise.
Dominique
I've applied this patch to gomp4 branch. It's the reworking of IFN_UNIQUE
suggested by Richard & Jakub.
1) IFN_UNIQUE is a ctrl-altering call, and thus ends up at the end of a BB.
2) tracer only needs to check that stmt (and it'a already looking at it for
other reasons)
3) IFN_UNIQUE is no lo
On 10/23/15 17:25, Nathan Sidwell wrote:
On 10/23/15 16:17, Cesar Philippidis wrote:
Nathan, can you try out this patch with your updated patch set? I saw
some test cases getting stuck when expanding expand_GOACC_DIM_SIZE in on
the host compiler, which is wrong. I don't see that happening in
go
Richard, Jakub,
here is an updated patch. Changes from previous version
1) Moved the subcodes to an enumeration in internal-fn.h
2) Remove ECF_LEAF
3) Added check in initialize_ctrl_altering
4) tracer code now (continues) to only look in last stmt of block
I looked at fnsplit and do not beli
On Fri, 2015-10-23 at 02:32 -0400, Rich Felker wrote:
> Here's my updated version of the FDPIC patch with all requested
> changes made and Changelog added. I've included all the original
> authors. This is my first time writing such an extensive Changelog
> entry so please let me know if there are
Jakub, Richard,
here's an updated version of patch 7, the early half of OpenACC lowering. I've
addressed all of Jakub's earlier comments.
The significant change is that now the head/tail unique markers are threaded
on a data dependency variable. I'd not noticed its lack being a problem, bu
It is not possible to access arbitrary stack frames on hppa. Committed to
trunk.
Dave
--
John David Anglin dave.ang...@bell.net
2015-10-25 John David Anglin
* g++.dg/Wno-frame-address.C: Skip on hppa*-*-*.
Index: g++.dg/Wno-frame-address.C
===
The attached change fixes a bug compiling the qtbase-opensource-src package.
It compares pointers
to method types. This failed as only FUNCTION_TYPES were canonicalized on hppa.
On 32-bit hppa, pointers to functions including methods point to non unique
function descriptors and need
canonicali
Hi Paul,
I had a look at your patch, especially at the allocate() specific part
and have nothing serious to complain about. I would love to see more
comments to help beginners find there way in the code, but that's a
thing I will never get. :-)
Therefore, from my perspective ok for trunk and than
Dear Andre,
I will gladly add some comments before I commit - no problem. Thanks
for the review.
Cheers
Paul
On 25 October 2015 at 16:47, Andre Vehreschild wrote:
> Hi Paul,
>
> I had a look at your patch, especially at the allocate() specific part
> and have nothing serious to complain about.
On 10/24/2015 11:38 PM, Jonathan Wakely wrote:
On 8 May 2015 at 15:05, Ed Smith-Rowland <3dw...@verizon.net> wrote:
On 05/07/2015 12:06 PM, Jonathan Wakely wrote:
Hi Ed,
The C++ committee is considering the
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4437.pdf
proposal to make C++1
The change of Andrew Dixie and David Edelsohn on 2015-09-18 introduced a new
define, EH_FRAME_THROUGH_COLLECT2, and broke EH frame handling on 32-bit
hppa*-*-hpux*. We now need to define EH_FRAME_THROUGH_COLLECT2 on
this target.
Tested on hppa2.0w-hp-hpux11.11. Committed to trunk.
Dave
--
John
It seems to me that there's a discrepancy in handling explicit
default constructors. Based on my tests, this works:
struct X {explicit X() {}};
void f(X) {}
int main()
{
f({});
}
However, if the explicit constructor is defaulted, gcc accepts the code:
struct X {explicit X() = default;};
v
On 25 October 2015 at 17:46, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> On 10/24/2015 11:38 PM, Jonathan Wakely wrote:
>>
>> On 8 May 2015 at 15:05, Ed Smith-Rowland <3dw...@verizon.net> wrote:
>>>
>>> On 05/07/2015 12:06 PM, Jonathan Wakely wrote:
Hi Ed,
The C++ committee i
Dear Andre,
Committed as revision 229303 with extra comments and tests for PR61819
and PR61830. I'll see what I can do to backport the fix for the
latter, since it is a revision.
Thanks for the review
Paul
On 25 October 2015 at 16:47, Andre Vehreschild wrote:
> Hi Paul,
>
> I had a look at yo
On 25 October 2015 at 22:15, Ville Voutilainen
wrote:
> It seems to me that there's a discrepancy in handling explicit
> default constructors. Based on my tests, this works:
>
> struct X {explicit X() {}};
>
> void f(X) {}
>
> int main()
> {
> f({});
> }
>
> However, if the explicit constructo
On 10/19/2015 05:33 AM, Marek Polacek wrote:
+ if (fold_p)
+ expr = fold_build1_loc (loc, NOP_EXPR, totype, expr);
+ else
+ expr = build1_loc (loc, NOP_EXPR, totype, expr);
Rather than duplicate code like this everywhere, maybe we should
introduce a
The attached patch fixes a segfault in f951 for some poorly
written invalid code. See the testcase for the code in
question. Built and tested on i386-*-freebsd. Ok to commit?
2015-10-25 Steven G. Kargl
PR fortran/36192
* array.c (gfc_ref_dimen_size): Check for BT_INTEGER bef
On 10/21/2015 01:57 PM, Richard Biener wrote:
> Ugh (stupid templates).
>
> @@ -387,10 +389,10 @@ base_pool_allocator ::allocate ()
>block = m_virgin_free_list;
>header = (allocation_pool_list*) allocation_object::get_data (block);
>header->next = NULL;
> -#ifdef ENABLE_CHE
The problem: Statement labels within a type declaration are put in the
statement label tree belonging to the type declaration's namespace's (instead
of the current namespace). When the line is otherwise empty and an error is
issued, gfc_free_st_label tries to delete the label from the label tr
For 32-bit targets p8vector_ok does not imply we have int128.
Tested with -m32,-m32/-mpowerpc64,-m64; okay for trunk?
Segher
2015-10-26 Segher Boessenkool
gcc/testsuite/
* gcc.target/powerpc/p8vector-builtin-8.c: Add "target int128".
---
gcc/testsuite/gcc.target/powerpc/p8vector-
The patterns involved can create vmadd resp. vnmsub instructions instead.
This patch changes the testcases to allow those.
Tested with -m32,-m32/-mpowerpc64,-m64; okay for trunk?
Segher
2015-10-26 Segher Boessenkool
gcc/testsuite/
* gcc.target/powerpc/vsx-builtin-2.c: Allow vmadd a
On Wed, Oct 21, 2015 at 11:55 AM, Bin.Cheng wrote:
> On Fri, Oct 9, 2015 at 8:04 PM, Bernd Schmidt wrote:
>> On 10/09/2015 02:00 PM, Bin.Cheng wrote:
>>>
>>> I further bootstrap and test attached patch on aarch64. Also three
>>> cases in spec2k6/fp are improved by 3~6%, two cases in spec2k6/fp a
30 matches
Mail list logo
