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 forays into reload, so went looking for ways to
get at the relo
Hello!
> Non-ancient assemblers support the "ud2" mnemonic, so there is no need
> to emit the literal opcode as data.
>
> OK for trunk and 4.8?
You forgot to tell us how the patch tested...
> gcc/
> 2014-02-13 Roland McGrath
>
> * configure.ac (HAVE_AS_IX86_UD2): New test for 'ud2' mnemonic.
Hi All,
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++
testcases.
The only other rule in these tests was for ! { *-*-darwin* }, so I'm not sure
if it's appropriate to modify
the s
Hi,
Attached patch adds a MicroBlaze specific pattern for checking line number and
generation of function in dg-function-on-line, in line with the mips method.
Changelog/testsuite
2014-02-13 David Holsgrove
* gcc/testsuite/lib/scanasm.exp (dg-function-on-line): Add
MicroBlaze specific pat
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 Mekala; Tom Shui
> Subject: Re: [Patc
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: [Patch, microblaze]: Add optimiz
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, microblaze]: Remove SECONDARY_MEMORY_NE
Committed as r207776.
--
Ilmir.
On 14/02/14 11:24, Andrew Pinski wrote:
> On Thu, Feb 13, 2014 at 4:15 PM, Kugan
> wrote:
>> Hi,
>>
>> Is there any reason why HFmode is not there in arm_preferred_simd_mode?
>> NEON does support this.
>
> Most likely because there is no support for Half-float in the vectorizer.
>
I can see t
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 shows that gcc crashes at the function
>> *compute_avail*,
>> i
Ping ^3
These fixes are very important to 4.8 ARM embedded users, as they rely on
strict volatile bitfields a lot. Please let them in 4.8.
> -Original Message-
> From: Joey Ye [mailto:joey...@arm.com]
> Sent: Saturday, February 08, 2014 10:42
> To: gcc-patches@gcc.gnu.org
> Subject: RE: [
On Thu, 13 Feb 2014, Steve Ellcey wrote:
> So let me make sure I understand this: host is where you run the
> testsuite from, build is where the compilation happens (probably the
> same as host for most people), and target is where the test program is
> executed.
Host is the system on which the
On Thu, Feb 13, 2014 at 4:15 PM, Kugan
wrote:
> Hi,
>
> Is there any reason why HFmode is not there in arm_preferred_simd_mode?
> NEON does support this.
Most likely because there is no support for Half-float in the vectorizer.
Thanks,
Andrew Pinski
>
> Cross regression tested for arm-none-linu
Hi,
Is there any reason why HFmode is not there in arm_preferred_simd_mode?
NEON does support this.
Cross regression tested for arm-none-linux-gnueabi with qemu and no new
regressions.
Attached patch enables this. Is this OK for stage1.
Thanks,
Kugan
gcc/
+2014-02-14 Kugan Vivekanandarajah
Did you read the patch? It uses an empirical configure check to
discover if the assembler does in fact support ud2.
On Thu, Feb 13, 2014 at 3:50 PM, Andrew Pinski wrote:
> On Thu, Feb 13, 2014 at 3:46 PM, Roland McGrath wrote:
>> Non-ancient assemblers support the "ud2" mnemonic, so there is no need
>> to emit the literal opcode as data.
>>
>> OK for trunk and 4.8?
>
> I changed this to use .word due to openbs
On Thu, Feb 13, 2014 at 3:46 PM, Roland McGrath wrote:
> Non-ancient assemblers support the "ud2" mnemonic, so there is no need
> to emit the literal opcode as data.
>
> OK for trunk and 4.8?
I changed this to use .word due to openbsd3.1:
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01347.html .
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 with no extra options but tha
Non-ancient assemblers support the "ud2" mnemonic, so there is no need
to emit the literal opcode as data.
OK for trunk and 4.8?
Thanks,
Roland
gcc/
2014-02-13 Roland McGrath
* configure.ac (HAVE_AS_IX86_UD2): New test for 'ud2' mnemonic.
* configure: Regenerated.
*
en looking for exit_phi.
> (vectorizable_live_operation): Fix up condition.
>
> * gcc.c-torture/compile/20140213.c: New test.
Ok.
r~
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 with no extra options but that if we specified some options
> on the testsuite run then the tests
re/compile/20140213.c: New test.
--- gcc/tree-vect-loop.c.jj 2014-02-05 15:28:10.0 +0100
+++ gcc/tree-vect-loop.c2014-02-13 15:36:38.117741038 +0100
@@ -1968,10 +1968,8 @@ vect_is_slp_reduction (loop_vec_info loo
FOR_EACH_IMM_USE_FAST (use_p, imm
On Thu, Feb 13, 2014 at 1:13 PM, Jonathan Wakely wrote:
> The LWG have decided that
> http://cplusplus.github.io/LWG/lwg-active.html#2213 is a defect.
>
> In our std::regex_replace we do not appear to update out in all places
> that we should.
1) Yes, the current implementation is buggy for not u
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 with no extra options but that if we specified some options
on the testsuite run then the tests would fail with this message in the
c++.log file:
Committed as r207767.
Indeed, I had an older version of makeinfo. Once I updated to the
latest version 5.2, I saw the warnings. Those are fixed by this patch.
Thanks,
Sharad
> On Tue, Feb 11, 2014 at 11:42 PM, Thomas Schwinge
> wrote:
>>
>> Hi!
>>
>> On Wed, 5 Feb 2014 16:33:19 -0800, Sharad Si
> +/* 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_running)
bool for threads_running. It looks like a count otherwise.
> +gomp_afte
On Thu, 13 Feb 2014, 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
On 02/03/2014 03:50 AM, Kyrill Tkachov wrote:
> +# For ARM, the -march option by itself conflicts with any -mcpu option that
> +# we might end up passing to the build, causing an error.
> +# Therefore we override the -mcpu option as well.
> +# This shouldn't affect tuning much because the affected
Committed to branch dmalcolm/jit:
This commit adds the ability for client code to look up GCC builtins by
name, potentially allowing GCC to optimize the resulting function usage
based on what it knows about the behavior of each builtin.
Note that if the optimizer can't eliminate the call, the gen
Ping?
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00069.html
On 03/02/14 11:50, Kyrill Tkachov wrote:
Hi all,
There is a slight issue with the libatomic Makefile for arm linux ifunc targets.
It adds an explicity -march=armv7-a option to the command line to enable
building the exclusive instruc
On Thu, Feb 13, 2014 at 9:48 AM, Mike Stump wrote:
> On Feb 13, 2014, at 8:41 AM, Teresa Johnson wrote:
>> On Wed, Feb 12, 2014 at 2:03 PM, Xinliang David Li
>> wrote:
>
> [ extra lines deleted ]
>
>>> Should non comdat function be skipped?
>>
>> We warn in drop_profile if this is not a COMDAT,
On Feb 13, 2014, at 8:41 AM, Teresa Johnson wrote:
> On Wed, Feb 12, 2014 at 2:03 PM, Xinliang David Li wrote:
[ extra lines deleted ]
>> Should non comdat function be skipped?
>
> We warn in drop_profile if this is not a COMDAT, as we should only
> have this case and reach the call in that ca
On 02/13/2014 03:17 AM, Alex Velenko wrote:
> +/* Sets "rmode" field of "FPCR" control register to
> + "FPROUNDING_ZERO". */
Comment is wrong, or at least misleading.
> +void __inline __attribute__ ((__always_inline__))
> +set_rounding_mode (uint32_t mode)
> +{
> + uint32_t r;
> +
> + /* Rea
Ping
- Original Message -
> Hi,
>
> the following patch adds missing handling of error_mark_node result of
> fname_decl within finish_fname.
>
> ChangeLog
>
> 2014-02-11 Kai Tietz
>
> PR c++/58835
> * semantics.c (finish_fname): Handle error_mark_node.
>
> Regressio
On Thu, Feb 13, 2014 at 1:55 PM, Uros Bizjak wrote:
>>> I've noticed that _mm512_permutexvar_epi[64|32] intrinsics
>>> have wrong arguments order. As per [1] first argument is index.
>>> For vmpermps/vpermpd intrinsics are fine, but I've changed tests
>>> to call CALC with same arg order as intri
(Looks like the comma in the Subject stopped this getting through;
resending with suitably edited Subject)
Committed to branch dmalcolm/jit:
gcc/jit/
* libgccjit.c (IS_ASCII_ALPHA): New macro.
(IS_ASCII_DIGIT): New macro.
(IS_ASCII_ALNUM): New macro.
(gcc_jit_conte
Hello!
No functional changes.
2014-02-13 Uros Bizjak
* config/i386/sse.md (xop_vmfrcz2): Generate const0 in
operands[2], not operands[3].
Tested on x86_64-pc-linux-gnu {,-m32} and committed to mainline SVN.
Uros.
Index: config/i386/sse.md
On 01/30/2014 12:42 AM, Andrey Belevantsev wrote:
> Hello,
>
> As detailed in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58960#c6,
> we fail to use the DF liveness info in the register pressure sensitive
> scheduling for the new blocks as we do not properly compute it in this
> case. The patch fi
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, applied on the mainline.
2014-02-13 Eric Botcazou
PR libffi/60073
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, applied on the mainline.
2014-02-13 Eric Botcazou
PR libffi/60073
Hi,
This patch rewrites the vst4_lane intrinsics in terms of RTL builtins.
Tested on aarch64-none-elf with no issues.
OK to queue for Stage 1?
Thanks,
James
---
gcc/
2014-02-13 James Greenhalgh
* config/aarch64/aarch64-builtins.c
(aarch64_types_storestruct_lane_qualifiers
> We are using the type of a bitfield field for the replacement which
> we IMHO should avoid because the FIELD_DECLs size is 24
> but the fields type TYPE_SIZE is 32 (it's precision is 24). That's
> all not an issue until you start to VIEW_CONVERT to such type
> (VIEW_CONVERT being a reference op
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:
>
> ThumbThumb2
>
> reload
Hi Ilmir!
On Thu, 13 Feb 2014 17:15:47 +0400, Ilmir Usmanov wrote:
> I fixed patch according to your review and ready to commit it. OK for
> GOMP4 branch?
Yes! :-) Congratulations, and thanks for promptly addressing the issues
raised during review. I'm aware this can be a bit of a boring or t
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 for commit?
Cheers,
Ian
2014-02-13 Ian Bolton
test
Hello,
Pinging this patch review request. Can someone involved in the
Objective-C language frontend have a quick look at the description of
the proposed features and tell me if it'd be ok to have them in the
trunk so I can go ahead and create proper patches?
Thanks,
Dimitris
On 02/06/2014
On Thu, 13 Feb 2014, Richard Biener wrote:
>
> This updates the recommended versions to match those I just put
> at ftp://gcc.gnu.org/pub/gcc/infrastructure/. It also mentions
> the possibility of doing in-tree builds and fixes PR59878 by
> re-wording the cloog install parts.
And this updates d
This updates the recommended versions to match those I just put
at ftp://gcc.gnu.org/pub/gcc/infrastructure/. It also mentions
the possibility of doing in-tree builds and fixes PR59878 by
re-wording the cloog install parts.
Committed.
Richard.
2014-02-13 Richard Biener
PR bootstrap
Hi Thomas!
Thanks a lot for your review!
I agree with all your notes.
On 11.02.2014 20:51, Thomas Schwinge wrote:
For ChangeLog files updates (on gomp-4_0-branch, use the respective
ChangeLog.gomp files, by the way), should just you be listed as the
author, or also your colleagues?
Thank you fo
On Thu, Feb 13, 2014 at 1:37 PM, Uros Bizjak wrote:
>> I've noticed that _mm512_permutexvar_epi[64|32] intrinsics
>> have wrong arguments order. As per [1] first argument is index.
>> For vmpermps/vpermpd intrinsics are fine, but I've changed tests
>> to call CALC with same arg order as intrinsic
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 found another suspicious use (jus
> 2014-02-12 Dominik Vogt
>
> * config/s390/s390.c (s390_asm_output_function_label):
> fix crash caused by bad second argument to warning_at() with -mhotpatch
> and nested functions (e.g. with gfortran)
Applied. Thanks!
-Andreas-
> 2014-02-12 Dominik Vogt
>
> * config/s390/s390.c (s390_asm_output_function_label):
> fix crash caused by bad second argument to warning_at() with -mhotpatch
> and nested functions (e.g. with gfortran)
Applied. Thanks!
-Andreas-
> 2014-02-13 Dominik Vogt
>
> * gcc.target/s390/hotpatch-compile-8.c: New test
Ok committed. Thanks!
-Andreas-
On Thu, Feb 13, 2014 at 11:44 AM, Kirill Yukhin wrote:
> I've noticed that _mm512_permutexvar_epi[64|32] intrinsics
> have wrong arguments order. As per [1] first argument is index.
> For vmpermps/vpermpd intrinsics are fine, but I've changed tests
> to call CALC with same arg order as intrinsic.
On Wed, Feb 12, 2014 at 6:51 PM, Eric Botcazou wrote:
>> I am not sure how to deal with this, given that we have mismatched
>> V_C_Es anyway, I'm inclined not to care and let the expander deal with
>> it. But at the same I understand that it is ugly and will certainly
>> cause somebody more heada
> 2014-02-12 Jakub Jelinek
>
> PR target/43546
> * expr.c (compress_float_constant): If x is a hard register,
> extend into a pseudo and then move to x.
>
> * gcc.target/i386/pr43546.c: New test.
OK, thanks.
--
Eric Botcazou
Hi,
This patch adds vrnd<*>_f64 aarch64 intrinsics. A testcase for those
intrinsics is added. Run a complete LE and BE regression run with no
regressions.
Is patch OK for stage-1?
2014-02-13 Alex Velenko
gcc/
* config/aarch64/aarch64-builtins.c (BUILTIN_VDQF_DF): Macro
add
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 found another suspicious use (just removed,
it cannot have triggered and it looks bogus
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-unknown-linux-gnu, m68k-unkno
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-unknown-linux-gnu, m68k-unknown-linux-gnu,
> s390x-ibm-linux-gnu
Hello,
I’ve noticed that _mm512_permutexvar_epi[64|32] intrinsics
have wrong arguments order. As per [1] first argument is index.
For vmpermps/vpermpd intrinsics are fine, but I’ve changed tests
to call CALC with same arg order as intrinsic. here is the same
problem (wrong argument order) with vrc
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-unknown-linux-gnu, m68k-unknown-linux-gnu,
s390x-ibm-linux-gnu, powerpc-ibm-aix7.1.0.0.
>
> XPASS:
dg-extract-results.sh is used to combine the various .sum.sep and .log.sep
files produced by parallel testing into single .sum and .log files.
It's written in a combination of shell scripts and awk, so stays well
within the minimum system requirements.
However, it seems to be quadratic in the numb
64 matches
Mail list logo
