On Fri, Feb 14, 2014 at 5:59 PM, Michael Meissner
wrote:
> When I added direct move support for ISA 2.07 (power8), I did not add direct
> move support for long double and _Decimal128 types. This patch adds the
> direct
> move support for those types when you are running in 64-bit mode. Now, the
On Fri, Feb 14, 2014 at 10:51:14PM +0100, Mikael Morin wrote:
> Hello,
>
> this bug is not a regression, but the patch shouldn't wreck the compiler
> too much on the other hand.
> The problem is a wrong number of arguments while generating code for the
> ichar intrinsic. The correct number is 2 w
I forgot to add the new test to my patches.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
2014-02-14 Michael Meissner
PR target/60203
* gcc.target/powerpc/pr60203.c: New test
When I added direct move support for ISA 2.07 (power8), I did not add direct
move support for long double and _Decimal128 types. This patch adds the direct
move support for those types when you are running in 64-bit mode. Now, there
are still the problems raised in PR 25972 on machines without di
Committed to branch dmalcolm/jit:
gcc/jit/
* libgccjit++.h (gccjit::type::zero): New method.
(gccjit::type::one): New method.
(gccjit::function::add_call): New family of overloaded methods.
gcc/testsuite/
* jit.dg/test-operator-overloading.cc (make_test_quadratic):
Hello,
this bug is not a regression, but the patch shouldn't wreck the compiler
too much on the other hand.
The problem is a wrong number of arguments while generating code for the
ichar intrinsic. The correct number is 2 without the kind argument and
3 with it.
The attached patch uses the gfc_in
On 02/14/2014 03:21 PM, Jan Hubicka wrote:
Hi,
the testcase would be wonderful - those bugs are hard to catch.
Yeah - hope to soon.
I fixed some issues
recently, so you may try recent snapshot if you didn't.
You may try -fno-devirtualize to see if the bug goes away (likely it will) and
you
m
Hi,
the testcase would be wonderful - those bugs are hard to catch. I fixed some
issues
recently, so you may try recent snapshot if you didn't.
You may try -fno-devirtualize to see if the bug goes away (likely it will) and
you
may try to look in -fdump-tree-all -fdump-ipa-all dumps where cxa_pure
On 02/10/2014 03:06 PM, Jeff Law wrote:
> + PR rtl-optimization/60131
> + * ree.c (get_extended_src_reg): New function.
> + (combine_reaching_defs): Use it rather than assuming location
> + of REG.
> + (find_and_remove_re): Verify first operand of extension is
> + a REG befo
Hi Jan,
I hope to report a bug soon, but in the meantime I wanted to let
you know that for the last month or so, the 4.9 branch has (I think) a
bug at O3, where my program gets:
pure virtual method called
terminate called without an active exception
Aborted
4.8 works fine.
I am gues
On 02/14/2014 12:21 AM, Jakub Jelinek wrote:
>> Any reason not to just run gomp_free_thread_pool from
>> gomp_after_fork_callback
>> directly? I see no restrictions on what kind of code is allowed to execute
>> during that callback.
>
> Well, fork is async signal safe function, so calling malloc
I'm OK with adding patterns in general, but I wonder if gcc would
produce better code if they were split into QImode ops earlier?
+ [(set (match_operand:HI 0 "register_operand" "=Av")
+ (and:HI (match_operand:HI 1 "register_operand" "0")
+ (match_operand:HI 2 "immed
> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Friday, February 14, 2014 12:34 PM
> To: Richard Biener; gcc-patches@gcc.gnu.org
> Cc: Iyer, Balaji V
> Subject: Re: [PATCH] Fix Cilk+ ICEs in the alias oracle
>
> On 02/13/14 05:47, Richard Biener wrote:
> > On Thu,
On Tue, Feb 11, 2014 at 2:21 PM, Teresa Johnson wrote:
> On Thu, Dec 19, 2013 at 10:19 PM, Teresa Johnson wrote:
>> On Thu, Dec 12, 2013 at 5:13 PM, Jan Hubicka wrote:
On Wed, Dec 11, 2013 at 1:21 AM, Martin Liška
wrote:
> Hello,
>I prepared a collection of systemtap gr
On 02/11/14 02:06, Eric Botcazou wrote:
I pondered changing the condition for swapping the insn order, but it
didn't seem worth it. I doubt we see many 3->2 combinations where I3 is
a JUMP_INSN, the result turns into two simple sets and the insn swapping
code you wrote decides it needs to swap t
On Fri, 14 Feb 2014, Jakub Jelinek wrote:
> On Fri, Feb 14, 2014 at 10:37:03AM -0700, Jeff Law wrote:
> > On 02/13/14 03:54, Richard Sandiford wrote:
> > >Richard Sandiford writes:
> > >>Hans-Peter Nilsson writes:
> > >>>On Tue, 4 Feb 2014, Rainer Orth wrote:
> > AFAICT the gcc.dg/binop-xor1.
On 02/13/14 21:48, David Holsgrove wrote:
Hi Michael, List,
-Original Message-
From: David Holsgrove
Sent: Wednesday, 22 January 2014 1:43 pm
To: 'Michael Eager'; gcc-patches@gcc.gnu.org
Cc: Edgar Iglesias; John Williams; Vidhumouli Hunsigida; Nagaraju Mekala
Subject: RE: [Patch, microb
On 02/13/14 21:48, David Holsgrove wrote:
Hi Michael,
-Original Message-
From: Michael Eager [mailto:ea...@eagerm.com]
Sent: Sunday, 26 January 2014 1:57 am
To: David Holsgrove
Cc: gcc-patches@gcc.gnu.org; Edgar Iglesias; John Williams; Vinod Kathail;
Vidhumouli Hunsigida; Nagaraju Meka
On 02/13/14 21:48, David Holsgrove wrote:
Hi Michael,
-Original Message-
From: Michael Eager [mailto:ea...@eagerm.com]
Sent: Sunday, 9 February 2014 2:58 am
To: David Holsgrove; gcc-patches@gcc.gnu.org
Cc: Edgar Iglesias; John Williams; Vidhumouli Hunsigida; Nagaraju Mekala
Subject: Re:
On Fri, Feb 14, 2014 at 10:37:03AM -0700, Jeff Law wrote:
> On 02/13/14 03:54, Richard Sandiford wrote:
> >Richard Sandiford writes:
> >>Hans-Peter Nilsson writes:
> >>>On Tue, 4 Feb 2014, Rainer Orth wrote:
> AFAICT the gcc.dg/binop-xor1.c test is XPASSing everywhere since about
> 201311
On Thu, Feb 13, 2014 at 10:58 PM, Uros Bizjak wrote:
> You forgot to tell us how the patch tested...
Right. It's a pretty obviously harmless change. I tested that the
configure check passes with binutils-2.22, and eyeball'd a -S compile of a
trivial function calling __builtin_trap() to see it u
On 02/13/14 03:54, Richard Sandiford wrote:
Richard Sandiford writes:
Hans-Peter Nilsson writes:
On Tue, 4 Feb 2014, Rainer Orth wrote:
AFAICT the gcc.dg/binop-xor1.c test is XPASSing everywhere since about
20131114:
Bah, missing analysis. "Everywhere" does not include cris-elf,
powerpc64-
On 02/13/14 05:47, Richard Biener wrote:
On Thu, 13 Feb 2014, Richard Biener wrote:
Cilk+ builds INDIRECT_REFs when expanding builtins (oops) and thus
those can leak into MEM_EXRs which will lead to ICEs later.
The following patch properly builds a MEM_REF instead. Grepping
for INDIRECT_REF I
On Fri, 2014-02-14 at 11:12 +, Richard Sandiford wrote:
> Using target in itself should be OK. The hostname for rsh/ssh should be
> [board_info $board hostname] rather than $board itself. So in this case
> [board_info "multi-sim/-EL" hostname] should be multi-sim. The usual way
> to set tha
On Fri, Feb 14, 2014 at 4:19 PM, Kai Tietz wrote:
> Adjusted my original testcase so that eax isn't redeclared and
> shadows. Additional moved
> initialization of eax_live up.
> ChangeLog
>
> 2014-02-14 Kai Tietz
>
> PR target/60193
> * config/i386/i386.c (ix86_expand_prologue): Use
>
On 14/02/14 16:34, Ian Bolton wrote:
>>> The pr59858.c testcase explicitly sets -msoft-float which is
>> incompatible
>>> with our -mfloat-abi=hard variant.
>>>
>>> This patch therefore should not be run if you have -mfloat-abi=hard.
>>>
>>> Tested with both variations for arm-none-eabi build.
>>>
> > The pr59858.c testcase explicitly sets -msoft-float which is
> incompatible
> > with our -mfloat-abi=hard variant.
> >
> > This patch therefore should not be run if you have -mfloat-abi=hard.
> >
> > Tested with both variations for arm-none-eabi build.
> >
> > OK for commit?
> >
> > Cheers,
> >
On 2/14/2014, 6:02 AM, Richard Earnshaw wrote:
On 13/02/14 15:10, Richard Earnshaw wrote:
On 11/02/14 19:43, Vladimir Makarov wrote:
This is one more version of the patch to fix the PR59535
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535
Here are the results of applying the patch:
On 02/14/2014 07:19 AM, Kai Tietz wrote:
> 2014-02-14 Kai Tietz
>
> PR target/60193
> * config/i386/i386.c (ix86_expand_prologue): Use
> rax register as displacement for restoring %r10, %rax.
> Additional fix wrong offset for restoring both-registers.
>
> ChangeLog testsuite
>
On Fri, Feb 14, 2014 at 04:50:34PM +0100, Bernd Schmidt wrote:
> How many offloaded functions do we really expect to have in an
> executable? I don't think that's likely to be a bottleneck.
First of all, this isn't just about offloaded functions, but also any
global variables that need to be mappe
On 02/14/2014 04:12 PM, Jakub Jelinek wrote:
On Fri, Feb 14, 2014 at 04:01:46PM +0100, Bernd Schmidt wrote:
What I'm currently trying to do is to use get_file_function_name,
which should provide a unique string that can be used to look up an
offloaded function. That was suggested by Nathan Sidwe
2014-02-14 16:20 GMT+01:00 Richard Henderson :
> On 02/14/2014 06:41 AM, Kai Tietz wrote:
>> + else
>> +{
>> + t = plus_constant (Pmode, eax, UNITS_PER_WORD);
>> + emit_move_insn (eax, t);
>> + t = gen_rtx_PLUS (Pmode, stack_pointer_rtx, eax);
>> +}
>
Hi,
Adjusted my original testcase so that eax isn't redeclared and
shadows. Additional moved
initialization of eax_live up.
ChangeLog
2014-02-14 Kai Tietz
PR target/60193
* config/i386/i386.c (ix86_expand_prologue): Use
rax register as displacement for restoring %r10, %rax.
A
On 02/14/2014 06:41 AM, Kai Tietz wrote:
> + else
> +{
> + t = plus_constant (Pmode, eax, UNITS_PER_WORD);
> + emit_move_insn (eax, t);
> + t = gen_rtx_PLUS (Pmode, stack_pointer_rtx, eax);
> +}
Uros is right that you don't need the move here: 8(rsp,
On Fri, Feb 14, 2014 at 04:01:46PM +0100, Bernd Schmidt wrote:
> What I'm currently trying to do is to use get_file_function_name,
> which should provide a unique string that can be used to look up an
> offloaded function. That was suggested by Nathan Sidwell, I'd
> forgotten that such a function e
On 02/14/2014 03:49 PM, Ilya Verbin wrote:
Hi Bernd and Thomas,
Are you planning to support offloading from DSO in PTX/CUDA
environment? If yes, how are you going to solve the problem of the
collision of function names from different DSOs?
What I'm currently trying to do is to use get_file_fu
On Fri, Feb 14, 2014 at 3:50 PM, Kai Tietz wrote:
> 2014-02-14 15:40 GMT+01:00 Uros Bizjak :
>> On Fri, Feb 14, 2014 at 2:48 PM, Kai Tietz wrote:
>>> 2014-02-14 13:55 GMT+01:00 Uros Bizjak :
Hello!
> 2014-02-14 Kai Tietz
>
> PR target/60193
> * config/i386/i38
2014-02-14 15:40 GMT+01:00 Uros Bizjak :
> On Fri, Feb 14, 2014 at 2:48 PM, Kai Tietz wrote:
>> 2014-02-14 13:55 GMT+01:00 Uros Bizjak :
>>> Hello!
>>>
2014-02-14 Kai Tietz
PR target/60193
* config/i386/i386.c (ix86_expand_prologue): Use
rax register as disp
Hi Bernd and Thomas,
Are you planning to support offloading from DSO in PTX/CUDA
environment? If yes, how are you going to solve the problem of the
collision of function names from different DSOs?
However, if we decide to use element-wise host-target address mapping,
there are opportunities to m
So, here is the asked more complex variant regarding
displacement-value-range of amd64-instruction and taking care that we
use constant-offsets instead of register-based displacement addressing
if possible.
ChangeLog
2014-02-14 Kai Tietz
PR target/60193
* config/i386/i386.c (ix86_expa
On Fri, Feb 14, 2014 at 2:48 PM, Kai Tietz wrote:
> 2014-02-14 13:55 GMT+01:00 Uros Bizjak :
>> Hello!
>>
>>> 2014-02-14 Kai Tietz
>>>
>>> PR target/60193
>>> * config/i386/i386.c (ix86_expand_prologue): Use
>>> rax register as displacement for restoring %r10, %eax.
>>>
>>> Regressi
On Fri, Feb 14, 2014 at 2:18 AM, Alan Modra wrote:
> On Wed, Feb 12, 2014 at 06:47:37PM +0100, Ulrich Weigand wrote:
>> Note that find_replacement itself already recurses into both sides
>> of a PLUS.
>
> Thanks, I missed seeing that. I'd analysed the bug and knew what
> needed doing from past fo
On 14/02/14 14:14, Richard Earnshaw wrote:
> On 14/02/14 13:47, Jakub Jelinek wrote:
>> On Fri, Feb 14, 2014 at 01:43:26PM +, Richard Earnshaw wrote:
>>> On 31/01/14 19:59, Kyle McMartin wrote:
2014-01-31 Kyle McMartin
PR pch/60010
* config/host-linux.c (TRY_EMPTY_VM
On 14/02/14 13:47, Jakub Jelinek wrote:
> On Fri, Feb 14, 2014 at 01:43:26PM +, Richard Earnshaw wrote:
>> On 31/01/14 19:59, Kyle McMartin wrote:
>>> 2014-01-31 Kyle McMartin
>>>
>>> PR pch/60010
>>> * config/host-linux.c (TRY_EMPTY_VM_SPACE): Define for AArch64.
>>>
>>
>> This is OK
2014-02-14 13:55 GMT+01:00 Uros Bizjak :
> Hello!
>
>> 2014-02-14 Kai Tietz
>>
>> PR target/60193
>> * config/i386/i386.c (ix86_expand_prologue): Use
>> rax register as displacement for restoring %r10, %eax.
>>
>> Regression-tested for x86_64-unknown-linux-gnu, and
>> x86_64-w64-ming
On Fri, Feb 14, 2014 at 01:43:26PM +, Richard Earnshaw wrote:
> On 31/01/14 19:59, Kyle McMartin wrote:
> > 2014-01-31 Kyle McMartin
> >
> > PR pch/60010
> > * config/host-linux.c (TRY_EMPTY_VM_SPACE): Define for AArch64.
> >
>
> This is OK, subject to RM approval.
Ok. Kyle, do y
On Fri, 14 Feb 2014, Richard Earnshaw wrote:
> On 31/01/14 19:59, Kyle McMartin wrote:
> > Hi,
> >
> > Similar to other architectures, failing to set TRY_EMPTY_VM_SPACE
> > results in a Segmentation Fault and ICE in cc1plus when using
> > precompiled headers and randomize_va_space is set. This pa
On 13/02/14 14:32, Ian Bolton wrote:
> Hi,
>
> The pr59858.c testcase explicitly sets -msoft-float which is incompatible
> with our -mfloat-abi=hard variant.
>
> This patch therefore should not be run if you have -mfloat-abi=hard.
>
> Tested with both variations for arm-none-eabi build.
>
> OK
On 31/01/14 19:59, Kyle McMartin wrote:
> Hi,
>
> Similar to other architectures, failing to set TRY_EMPTY_VM_SPACE
> results in a Segmentation Fault and ICE in cc1plus when using
> precompiled headers and randomize_va_space is set. This patch fixes the
> issue, and now I can reliably build packag
On Fri, Feb 14, 2014 at 3:50 AM, dxq wrote:
> Richard Biener-2 wrote
>> On Sat, Feb 8, 2014 at 8:29 AM, dxq <
>
>> ziyan01@
>
>> > wrote:
>>> hi all,
>>>
>>> We found that gcc would run out of memory on Windows when compiling a
>>> *big*
>>> function (10 lines).
>>>
>>> More investigation show
The following avoids speculating loads in phiprop (sth it was never
supposed to do). That fixes the crashes in the PR.
Bootstrap and regtest ongoing on x86_64-unknown-linux-gnu.
Richard.
2014-02-14 Richard Biener
PR tree-optimization/60183
* tree-ssa-phiprop.c (propagate_wi
Hello Gerald,
Thanks, for your inputs.
Updated patch in the bottom.
On 12 Feb 01:12, Gerald Pfeifer wrote:
> Is there an option to enable all of them together?
Not yet since we have no product in the market and
all can be changed.
If no objection I'll commit it tomorrow.
--
Thanks, K
Index: htd
Hello!
> 2014-02-14 Kai Tietz
>
> PR target/60193
> * config/i386/i386.c (ix86_expand_prologue): Use
> rax register as displacement for restoring %r10, %eax.
>
> Regression-tested for x86_64-unknown-linux-gnu, and
> x86_64-w64-mingw32, and i686-w64-mingw32. Ok for apply?
No, you s
Hi DJ,
The patch below adds some missing instruction patterns to the RL78
backend. Missing in the sense that gcc generates the RTL even
if the patterns are not present in the backend and then triggers an
ICE because they cannot be matched. It is not clear to me why this
should be happe
On Fri, Feb 14, 2014 at 11:51:43AM +0100, Richard Biener wrote:
> This removes streaming of cl_target_option (we can't stream
> pointers in it). The info was redundant given that we do stream
> the target attribute itself. So the following patch re-builds
> DECL_FUNCTION_SPECIFIC_TARGET at tree l
Hi,
ChangeLog
2014-02-14 Kai Tietz
PR target/60193
* config/i386/i386.c (ix86_expand_prologue): Use
rax register as displacement for restoring %r10, %eax.
Regression-tested for x86_64-unknown-linux-gnu, and
x86_64-w64-mingw32, and i686-w64-mingw32. Ok for apply?
Regards,
Kai
I
Steve Ellcey writes:
> On Thu, 2014-02-13 at 23:09 +, Joseph S. Myers wrote:
>> On Thu, 13 Feb 2014, Steve Ellcey wrote:
>>
>> > While testing the C++ profiling tests in g++.dg/bprob and using the
>> > qemu simulator we discovered that these tests were passing when we ran
>> > the testsuite
On 13/02/14 15:10, Richard Earnshaw wrote:
> On 11/02/14 19:43, Vladimir Makarov wrote:
>> This is one more version of the patch to fix the PR59535
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535
>>
>> Here are the results of applying the patch:
>>
>> Thu
.. I think it would be cleaner to have new, separate testcases, named
after 2213. This is what we always did in the past when we implemented
resolutions of DRs.
At minimum, refer to 2213 in a comment.
Paolo.
On 14/02/14 09:57, Bernd Edlinger wrote:
> Hi,
>
> this test case fails on ARM, because this target has by default unsigned char
> type.
>
> Attached please find my proposed (almost obvious) fix for this,
> by using signed char, instead of char alone.
>
>
> Boot-Strapped and tested on X86_64 a
This removes streaming of cl_target_option (we can't stream
pointers in it). The info was redundant given that we do stream
the target attribute itself. So the following patch re-builds
DECL_FUNCTION_SPECIFIC_TARGET at tree loading time (we need it
during WPA inline analysis as well).
LTO boots
> Eric, sorry to rain on your parade, but you're making the same mistake
> I did at first when adding powerpc64le support to libffi. libffi is
> built as a shared library. You can't add a field to ffi_cif like this
> and uncondionally write to it: An application linked against an older
> version
Hi,
this test case fails on ARM, because this target has by default unsigned char
type.
Attached please find my proposed (almost obvious) fix for this,
by using signed char, instead of char alone.
Boot-Strapped and tested on X86_64 and ARM.
Thanks
Bernd.
On Thu, Feb 13, 2014 at 05:18:10PM +0100, Eric Botcazou wrote:
> This adds proper variadic support to the SPARC port of libffi, thus fixing a
> regression in the testsuite in 64-bit mode, and fixes a small inaccuracy in
> the documentation.
>
> Tested on SPARC/Solaris and SPARC64/Solaris, applie
On Fri, Feb 14, 2014 at 09:21:24AM +0100, Jakub Jelinek wrote:
> Well, fork is async signal safe function, so calling malloc/free, or any
> kind of synchronization primitives is completely unsafe there.
>
> The only safe thing could be to atomically or in some global flag (or set
> some TLS flag?)
On Thu, Feb 13, 2014 at 01:22:41PM -0800, Richard Henderson wrote:
> > +/* This is to enable best-effort cleanup after fork. */
> > +static int gomp_we_are_forked = 0;
>
> bool, no explicit initialization, possible removal, see below.
>
> > +static void
> > +gomp_free_thread_pool (int threads_ru
Hi,
I notice the implementation of nreverse() would change the original tree list.
It is not good if the argument is an attributes list of current function.
Since the rationale of using it, in nds32 port, is just to display the
attributes in the order that user specifies, I think it is ok not to u
Hi,
There are few typo in comment of nds32 port.
Fixed them as obvious, committed as Rev.207775.
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 207774)
+++ gcc/ChangeLog (revision 207775)
@@ -1,5 +1,10 @@
2014-02-
Hi,
In the gcc/config/nds32/nds32.c, there is one function definition which
does not follow GNU coding standards:
http://www.gnu.org/prep/standards/standards.html
Section "5.1 Formatting Your Source Code"
For a function definition, its function name should start in column one.
Fixed it as obv
On Feb 13, 2014, at 10:07 PM, David Holsgrove
wrote:
> I've attached a patch to extend the regex pattern to include optional 'ext'
> at the end of
> '.weak' to match the MicroBlaze weak label '.weakext' in two of the g++ test
> cases.
I don’t feel strongly either way. I'd like think weak(_def
70 matches
Mail list logo
