On Sat, Apr 11, 2015 at 11:37:47AM +0100, Jiangjiji wrote:
> Hi,
> This is a ping for: https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00772.html
> Regtested with aarch64-linux-gnu on QEMU.
> This patch has no regressions for aarch64_be-linux-gnu big-endian target
> too.
> OK for the trunk?
Hello world,
this is an update of the matmul inline patch. The only difference to
the last version is that it has the ubound simplification taken out.
Any further comments? OK for trunk?
Thomas
2015-05-05 Thomas Koenig
PR fortran/37131
* gfortran.h (gfc_isym_id):
On Sat, Apr 25, 2015 at 12:26:16AM +0100, Kugan wrote:
>
> Thanks for the review. I have updated the patch based on the comments
> with some other minor changes. Bootstrapped and regression tested on
> aarch64-none-linux-gnu with no-new regressions. Is this OK for trunk?
>
>
> Thanks,
> Kugan
>
On May 4, 2015 11:38:42 PM GMT+02:00, Eric Botcazou
wrote:
>> 2015-05-01 Eric Botcazou
>>
>> * expr.c (expand_expr_real_1) : Try to substitute
>constants
>> on the RHS of expressions.
>> * gimple-expr.h (is_gimple_constant): Reorder.
>
>Bummer. This breaks C++ debugging:
>
>+F
Hello!
Another pattern that seems useful.
2015-05-05 Uros Bizjak
PR target/65871
* config/i386/i386.md (*bmi_andn__ccno): New pattern.
testsuite/ChangeLog:
2015-05-05 Uros Bizjak
PR target/65871
* gcc.target/i386/pr65871-3.c: New test.
Teste on x86_64-linux-gnu {,-m32}
From: Trevor Saunders
Hi,
here's what I committed. bootstrapped + regtested x86_64-linux-gnu.
Trev
Using a named bitfield with a width more than 0 means we won't hit
weirdness caused by the bitfield not really needing to exist. Changing
int to long long means we won't have trouble with some
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Tuesday, April 28, 2015 12:27 AM
> OK. No need for heroics -- give it a shot, but don't burn an insane
> amount of time on it. If we can't get to a reasonable testcase, then so
> be it.
Ok, I tried but really didn't managed to create a testcase.
The code handling parameter DIEs needed a little tweaking for variable
length template arguments. I've relaxed the original assert, but this
may require tweaking at branch review time-- hopefully later this week.
Committing to branch.
Aldy
p.s. Richi/Jason: Winter is coming. Down to 1 GCC r
On 02/05/15 19:56 +0100, Jonathan Wakely wrote:
One last patch before I head to Lenexa, this fixes the long standing
not-a-bug that our default launch policy is launch::deferred.
This way std::async with no explicit policy or with any policy that
contains launch::async will run in a new thread.
Hi,
if my wifi connectoin allows, I will commit the following patch I tested in
meantime. It also adds sanity checking for TYPE_MAXVAL that does not seem to
trigger any issues anymore.
>From type_non_common it remains to check values and binfo. I hope to kill all
those fields and move them to der
On 03/06/2015 07:33 AM, Michael Eager wrote:
On 03/05/15 21:12, Ajit Kumar Agarwal wrote:
Changes are incorporated. Please find the log of the updated patch.
commit 91f275c144165320850ddf18e3a1e059a66c
Author: Ajit Kumar Agarwal
Date: Fri Mar 6 09:55:11 2015 +0530
[Patch,micro
On 03/04/2015 08:20 AM, Michael Eager wrote:
On 03/04/15 03:53, Ajit Kumar Agarwal wrote:
-Original Message-
From: Michael Eager [mailto:ea...@eagerm.com]
Sent: Thursday, February 26, 2015 4:33 AM
To: Ajit Kumar Agarwal; GCC Patches
Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hun
On Mon, May 4, 2015 at 3:49 PM, Yunlian Jiang wrote:
> There was a similar disscussion here
> https://gcc.gnu.org/ml/gcc/2005-11/msg01190.html
That was a discussion about libiberty. Your subject says you have
trouble building gdb.
Can you describe the exact problem that you are having? What
pr
> > Not obvious enough, it seems: this patch broke gnat.dg/lto* tests at
> > least on i386-pc-solaris2.10. E.g.
> >
> > FAIL: gnat.dg/lto1.adb (test for excess errors)
> > WARNING: gnat.dg/lto1.adb compilation failed to produce executable
> >
> > FAIL: gnat.dg/lto1.adb (test for excess errors)
>
I've reverted my latest match.pd change. It's causing a bootstrap
failure on i686.
Jeff
I've committed the attached patch to fix PR target/65987
which is a 6 regression. The recent stdarg change reveals
the target problem for section crossing jumps.
Some SH specific jump optimizations don't take into account
such jumps. The attached patch is a minimal fix to solve
the above PR. Tes
There was a similar disscussion here
https://gcc.gnu.org/ml/gcc/2005-11/msg01190.html
The problem is in the configure stage, the __GNU_SOURCE is not
defined, and it could not find
the declaration of asprintf. so it make a declaration of asprintf in
libiberty.h. And for the file floatformat.c,
the
> 2015-05-01 Eric Botcazou
>
> * expr.c (expand_expr_real_1) : Try to substitute constants
> on the RHS of expressions.
> * gimple-expr.h (is_gimple_constant): Reorder.
Bummer. This breaks C++ debugging:
+FAIL: gdb.cp/class2.exp: print alpha at marker return 0
+FAIL: gdb.cp
> OK. Fixed the patch. Rebased and tested on x86_64-linux (fortunately, it
> did not conflict with Trevor's series of rtx_insn-related patches).
good :) fwiw I have another series that'll probably be ready about the
end of the week (the punishment for writing small patches is making the
testing bo
Hi Ramana! Sorry to bother, but I looked at the repository and didn't
see this committed. As I don't have write access could you please
commit this for me?
Thanks a lot!
On Tue, Apr 28, 2015 at 2:07 PM, Martin Galvan
wrote:
> Thanks a lot. I don't have write access to the repository, could you
>
On 05/01/2015 06:56 PM, David Malcolm wrote:
This patch eliminates the union in struct line_map in favor of
a simple class hierarchy, making struct line_map a base class,
with line_map_ordinary and line_map_macro subclasses.
The patch eliminates all usage of linemap_check_ordinary and
linemap_ch
(the original message was bounced by the mailing list, resending with
compressed attachment)
On 30.04.2015 8:00, Jeff Law wrote:
>
> Can you please check the changes to do_jump_1, the indention looked
> weird in the patch. If it's correct, just say so.
It is ok. Probably that's because the surr
Hi
Here is the patch to demangle symbols in debug messages. I have
also simplify code in formatter.h.
Here is an example of assertion message:
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/debug/functions.h:213:
error: function requires a valid iterator ra
On 05/04/2015 01:17 PM, Paolo Carlini wrote:
This regression is a more subtle variant of c++/65858: if the user
passes -Wno-error=narrowing the pedwarn didn't result in an actual error
(even if we are forcing -pedantic-errors around it) but produces anyway
a warning, thus returns true, and ok isn
I think this caused:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66009
H.J.
On Mon, May 4, 2015 at 2:02 AM, Richard Biener
wrote:
> On Sat, May 2, 2015 at 2:36 AM, Jeff Law wrote:
>> Here's an updated patch to add more type narrowing to match.pd.
>>
>> Changes since the last version:
>>
>> S
Hello!
2015-05-04 Uros Bizjak
* config/i386/i386.c: Change GET_CODE (...) == CONST_DOUBLE check
to CONST_DOUBLE_P predicate.
(standard_sse_constant_p): Return 0 for !TARGET_SSE.
(ix86_legitimate_constant_p) : For 32bit targets,
allow only operands that satisfy standard_sse_
This is an old thread and we are still running into similar issues:
Code is not being vectorized on 64-bit target due to scev not being
able to optimally analyze overflow condition.
While the original test case shown here seems to work now, it does not
work if the start value is not a constant and
On 05/04/2015 12:16 PM, Jakub Jelinek wrote:
Hi!
The code I've added in r217755 was assuming that stmt_could_throw_p
memory read will always end a bb, but that is clearly not the case.
Thus, the following patch uses stmt_ends_bb_p instead.
Bootstrapped/regtested on x86_64-linux and i686-linux,
On 05/01/2015 06:56 PM, David Malcolm wrote:
As a relative newcomer to GCC, one of the issues I had was
becoming comfortable with the linemap API and its internal
representation.
To familiarize myself with it, I wrote a dumping routine
to try to visualize how the source_location space is carved
On 05/01/2015 06:56 PM, David Malcolm wrote:
libcpp makes extensive use of the C preprocessor. Whilst this has a
pleasingly self-referential quality, I find the code hard-to-read;
implementing source location support in my JIT branch was much harder than
I felt it should have been.
In an attemp
Hi!
The code I've added in r217755 was assuming that stmt_could_throw_p
memory read will always end a bb, but that is clearly not the case.
Thus, the following patch uses stmt_ends_bb_p instead.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/5?
2015-05-04 Jakub Jelinek
Hi,
unfortunately we have to return to these few lines of code :(
This regression is a more subtle variant of c++/65858: if the user
passes -Wno-error=narrowing the pedwarn didn't result in an actual error
(even if we are forcing -pedantic-errors around it) but produces anyway
a warning, thus
On 05/01/2015 09:30 PM, tbsaunde+...@tbsaunde.org wrote:
From: Trevor Saunders
Hi,
This adds a configure check to libobjc to find out if types of bitfields effect
their layout, and uses it to replace the rather broken usage of
PCC_BITFIELD_TYPE_MATTERS.
bootstrapped + regtested x86_64-linux-g
On 05/04/2015 11:39 AM, Jakub Jelinek wrote:
On Mon, May 04, 2015 at 11:34:05AM -0600, Jeff Law wrote:
On 05/04/2015 10:37 AM, Alexander Monakov wrote:
This patch introduces option -fno-plt that allows to expand calls that would
go via PLT to load the address of the function immediately at call
On Mon, May 04, 2015 at 11:34:05AM -0600, Jeff Law wrote:
> On 05/04/2015 10:37 AM, Alexander Monakov wrote:
> >This patch introduces option -fno-plt that allows to expand calls that would
> >go via PLT to load the address of the function immediately at call site
> >(which
> >introduces a GOT load
On 05/04/2015 10:37 AM, Alexander Monakov wrote:
With this patch at hand, I'd like to discuss a code generation problem, which
my patch solves only partially. FWIW, it passes bootstrap/regtest on x86-64.
With other patches in series applied, GCC with -fno-plt can generate tail
calls in PIC mode
On 05/04/2015 10:37 AM, Alexander Monakov wrote:
This patch introduces option -fno-plt that allows to expand calls that would
go via PLT to load the address of the function immediately at call site (which
introduces a GOT load). Cover letter explains the motivation for this patch.
New option do
On 05/01/2015 02:33 PM, Sandra Loosemore wrote:
Re https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01510.html :
On 04/15/2015 10:42 PM, Jeff Law wrote:
It looks very sane to me. This is probably how the AVR and CR16 should
have been handled to begin with IMHO.
FWIW, I generally discourage ports
yes -- a full solution that supports lazy binding will be nice.
David
On Mon, May 4, 2015 at 9:58 AM, Michael Matz wrote:
> Hi,
>
> On Mon, 4 May 2015, Xinliang David Li wrote:
>
>> The use case proposed by Sri allows user to selectively eliminate PLT
>> overhead for hot external calls only.
>
>
On 05/01/2015 06:56 PM, David Malcolm wrote:
This patch updates and expands some comments in libcpp, adding
a big table to try to clarify what an individual source_location
value can mean.
libcpp/ChangeLog:
* include/line-map.h: Fix comment at the top of the file.
(source_locatio
On 05/02/2015 03:01 PM, tbsaunde+...@tbsaunde.org wrote:
From: Trevor Saunders
Hi,
This set of patches changes rtx to rtx_insn * in many plaes where its fairly
trivial to do so.
each was bootstrapped + regtested on x86_64-linux-gnu, and the series was run
through config-list.mk. I believe th
On 05/04/2015 05:50 AM, Dominik Vogt wrote:
This patch removes a "write only" variable from the C++ code.
ChangeLog:
--
2015-05-04 Dominik Vogt
* call.c (print_z_candidates): Remove dead code.
OK. Please install.
FWIW, removing a write-only variable seems like it ought ot fall u
On 05/02/2015 03:17 PM, Bernhard Reutner-Fischer wrote:
I should find time to commit the already approved auto-wipe dump file patch.
So let's assume I'll get to it maybe next weekend and nobody will notice the 2
leftover .original dumps in this patch :)
Doh! Not sure how there's be a .original
Hi,
On Mon, 4 May 2015, Xinliang David Li wrote:
> The use case proposed by Sri allows user to selectively eliminate PLT
> overhead for hot external calls only.
Yes, but only _because_ his approach doesn't use lazy binding. With the
full solution such restriction to a subset of functions isn't
The use case proposed by Sri allows user to selectively eliminate PLT
overhead for hot external calls only. In such scenarios, lazy binding
won't be something matters to the user.
David
On Mon, May 4, 2015 at 7:45 AM, Michael Matz wrote:
> Hi,
>
> On Thu, 30 Apr 2015, Sriraman Tallam wrote:
>
>>
With this patch at hand, I'd like to discuss a code generation problem, which
my patch solves only partially. FWIW, it passes bootstrap/regtest on x86-64.
With other patches in series applied, GCC with -fno-plt can generate tail
calls in PIC mode more frequently, but sometimes poorer code is gene
This patch introduces option -fno-plt that allows to expand calls that would
go via PLT to load the address of the function immediately at call site (which
introduces a GOT load). Cover letter explains the motivation for this patch.
New option documentation for invoke.texi is missing from the pat
On i386, peepholes that transform memory load and register-indirect jump into
memory-indirect jump are overly restrictive in that they don't allow combining
when the jump target is loaded into %eax, and the called function returns a
value (also in %eax, so it's not dead after the call). Fix this b
With -fno-plt, we don't have to reject even direct calls as sibcall
candidates.
This patch depends on '-fplt' flag that is introduced in another patch.
This patch requires that with -fno-plt all sibcall candidates go through
prepare_call_address that transforms the call to a GOT lookup.
OK?
In the i386 backend, tailcalls are incorrectly disallowed in PIC mode for
calls via function pointers on the basis that indirect calls, like direct
calls, would go via PLT and thus require %ebx to point to GOT -- but that is
not true. Quoting Rich Felker who reported the bug,
"For PLT slots in
On 32-bit x86, register class CLOBBERED_REGS is a proper subset of
LEGACY_REGS, which causes IRA not to consider it separately for register
allocation, even when it has lower cost than other classes. This patch is
useful to fix code generation problem that appears with no-PLT PIC tailcalls.
Was t
Recent post by Sriraman prompts me to post my -fno-plt approach sooner rather
than later; I was working on no-PLT PIC codegen in last few days too.
Although I'm posting a patch series, half of it is i386 backend tuning and can
go in independently. Except one patch where it's noted specifically, th
All,
I committed the below as obvious.
Andreas
2015-05-04 Andreas Tobler
* config/arm/arm.c: Restore bootstrap.
Index: config/arm/arm.c
===
--- config/arm/arm.c(revision 222767)
+++ config/arm/arm.c(working co
On Sat, May 02, 2015 at 04:16:18PM -0400, Ed Smith-Rowland wrote:
> This extends' static assert to not require a message string.
> I elected to make this work also for C++11 and C++14 and warn only with
> -pedantic.
> I think many people just write
> static_assert(thing, "");
> .
>
> I took the
On Mon, May 04, 2015 at 10:11:13AM +0200, Richard Biener wrote:
> Not sure how this helps when SRA tears apart the parameter. That is,
> isn't the important thing that both the IPA modified function argument
> types/decls have the same type as the types of the parameters SRA ends
> up passing? (a
Hi all,
I like to present here a first patch for using class arrays in associate. Upto
now gfortran crashed, when a class array-section/element was selected in an
associate. This patch fixes this now for class array sections as well as for
single elements.
The story of the patch is told quite sho
> Not obvious enough, it seems: this patch broke gnat.dg/lto* tests at
> least on i386-pc-solaris2.10. E.g.
>
> FAIL: gnat.dg/lto1.adb (test for excess errors)
> WARNING: gnat.dg/lto1.adb compilation failed to produce executable
>
> FAIL: gnat.dg/lto1.adb (test for excess errors)
> Excess errors
Hi,
On Thu, 30 Apr 2015, Sriraman Tallam wrote:
> We noticed that one of our benchmarks sped-up by ~1% when we eliminated
> PLT stubs for some of the hot external library functions like memcmp,
> pow. The win was from better icache and itlb performance. The main
> reason was that the PLT stub
Andreas Schwab writes:
> Rainer Orth writes:
>
>> You cannot expect printf to print "(nil)" or variant for NULL pointers.
>> E.g. on Solaris 10 you get a SEGV instead.
>
> You are probably mixing it up with %s. %p is required to handle NULL
> like any other valid pointer value.
Seems so. Sorr
Rainer Orth writes:
> You cannot expect printf to print "(nil)" or variant for NULL pointers.
> E.g. on Solaris 10 you get a SEGV instead.
You are probably mixing it up with %s. %p is required to handle NULL
like any other valid pointer value.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.or
Jan Hubicka writes:
> Hi,
> this patch extends verify_type to check various uses of TYPE_MINVAL.
> I also added check that MIN_VALUE have compatible type with T:
> useless_type_conversion_p (const_cast (t), TREE_TYPE (TYPE_MIN_VALUE
> (t)))
> but that one fails interesting ways for C sizetype
On 2015-05-04 4:32 AM, Thomas Schwinge wrote:
Dave, would you please test the following patch, and report the
regression status compared to before r222620? (Compared to your existing
r222021 results, as posted in the PR, for example.)
With patch, we have the following fails on hppa2.0w-hp-hpux1
This fixes a missed vectorization of a function in paq8p. Without
merged PHI nodes phiopt doesn't recognize adjacent MIN/MAX_EXPRs.
Certainly no other pass I schedule mergephi over cares for merged
PHIs (DCE might even be confused here).
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
On Mon, 4 May 2015, Richard Biener wrote:
On Sat, May 2, 2015 at 12:46 AM, Marc Glisse wrote:
Hello,
this patch tries to tighten a bit the range estimate for x%y. slp-perm-7.c
started failing by vectorizing more than expected, I assumed it was a good
thing and updated the test. I am less cons
Thomas Schwinge writes:
> Additionally to the "%p" format specifier printing a "0x" prefix vs. not
> doing that, I've also changed the expected "(nil)" output for NULL
> pointers to instead match basically everything.
You cannot expect printf to print "(nil)" or variant for NULL pointers.
E.g. o
> On 04 May 2015, at 02:32, David Edelsohn wrote:
>
> On Sat, May 2, 2015 at 6:04 AM, Eric Botcazou wrote:
>>> Why should GCC unnecessarily create stack frames to avoid
>>> compare-debug testcase failures?
>>
>> I'm not sure I understand the question... compare-debug failures are failures
>> (
This patch removes a "write only" variable from the C++ code.
ChangeLog:
--
2015-05-04 Dominik Vogt
* call.c (print_z_candidates): Remove dead code.
--
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
>From 6943ad84a5a5b69c7cf5df1ea5bb6ab5fd254825 Mon Sep 17 00:00:00 2001
From
On Mon, May 4, 2015 at 4:15 AM, Richard Biener wrote:
>
> The following fixes PR65935 where the vectorizer is confused after
> SLP operands swapping to see the stmts in the IL with unswapped
> operands. As we already swap for different def-kinds just swap
> for other swaps as well.
>
> Bootstrap
The following fixes PR65935 where the vectorizer is confused after
SLP operands swapping to see the stmts in the IL with unswapped
operands. As we already swap for different def-kinds just swap
for other swaps as well.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2015-05
We don't support vectorizing group stores with gaps - so the natural
thing is to just split groups at such boundaries which enables
more BB vectorization (and likely loop vectorization as well, though
that would be some weird cases I suspect).
Bootstrap and regtest running on x86_64-unknown-linux
According to your opinion, I split the backports of pr64304 into 2
emails, and this one is for 4.9 branch.
This patch backport the fix of PR target/64304 , miscompilation with
-mgeneral-regs-only, to the 4.9 branch from trunk r219844. Tested on
x86_64 by using qemu of aarch64.
OK for 4.9?
diff
On Mon, 4 May 2015, Jakub Jelinek wrote:
> On Mon, May 04, 2015 at 11:31:11AM +0200, Richard Biener wrote:
> > On Mon, 4 May 2015, Jakub Jelinek wrote:
> >
> > > On Mon, May 04, 2015 at 11:13:51AM +0200, Rainer Orth wrote:
> > > > Jakub Jelinek writes:
> > > >
> > > > > On Thu, Apr 23, 2015 at
On Mon, May 04, 2015 at 11:31:11AM +0200, Richard Biener wrote:
> On Mon, 4 May 2015, Jakub Jelinek wrote:
>
> > On Mon, May 04, 2015 at 11:13:51AM +0200, Rainer Orth wrote:
> > > Jakub Jelinek writes:
> > >
> > > > On Thu, Apr 23, 2015 at 04:31:52PM -0700, H.J. Lu wrote:
> > > >> Hi,
> > > >>
According to your opinion, I split the backports of pr64304 into 2
emails, and this one is for 4.8 branch.
This patch backport the fix of PR target/64304 , miscompilation with
-mgeneral-regs-only, to the 4.8 branch from trunk r219844. Tested on
x86_64 by using qemu of aarch64.
OK for 4.8?
dif
> Hum, the fact that your earlier version created wrong code
> (get_gimple_for_ssa_name
> already returned false here) points at some issues with
> EXPAND_INITIALIZER as well, no...?
Theoritically yes but, in practice, EXPAND_INITIALIZER is used in varasm.c and
for debugging stuff only, so I don'
On Mon, 4 May 2015, Jakub Jelinek wrote:
> On Mon, May 04, 2015 at 11:13:51AM +0200, Rainer Orth wrote:
> > Jakub Jelinek writes:
> >
> > > On Thu, Apr 23, 2015 at 04:31:52PM -0700, H.J. Lu wrote:
> > >> Hi,
> > >>
> > >> I checked this patch into gcc-5-branch.
> > >
> > > That's wrong accordin
> Hi Christian,
> I noticed case gcc.dg/ipa/iinline-attr.c failed on aarch64. The
> original patch is x86 specific, while the case is added as general
> one. Could you please have a look at this?
>
> FAIL: gcc.dg/ipa/iinline-attr.c scan-ipa-dump inline
> "hooray[^\\n]*inline copy in test"
>
t
On Mon, May 04, 2015 at 11:13:51AM +0200, Rainer Orth wrote:
> Jakub Jelinek writes:
>
> > On Thu, Apr 23, 2015 at 04:31:52PM -0700, H.J. Lu wrote:
> >> Hi,
> >>
> >> I checked this patch into gcc-5-branch.
> >
> > That's wrong according to https://gcc.gnu.org/develop.html#num_scheme
>
> HJ has
Jakub Jelinek writes:
> On Thu, Apr 23, 2015 at 04:31:52PM -0700, H.J. Lu wrote:
>> Hi,
>>
>> I checked this patch into gcc-5-branch.
>
> That's wrong according to https://gcc.gnu.org/develop.html#num_scheme
HJ has a point, though: with DEV-PHASE remaining empty, all post-5.1.0
versions of gcc
Hi,
This patch fixes two ARM testcases that require target to be Thumb2
effective. One is built for Cortex-m3, the purpose of the second one
is to generate thumb2_addsi3_compare0_scratch insn and both are
failing when compiled for armv5t for instance.
Built and regtested, is it OK for trunk ?
T
On Sat, May 2, 2015 at 2:36 AM, Jeff Law wrote:
> Here's an updated patch to add more type narrowing to match.pd.
>
> Changes since the last version:
>
> Slight refactoring of the condition by using types_match as suggested by
> Richi. I also applied the new types_match to 2 other patterns in mat
Hi Marcus,
On 1 May 2015 at 17:18, Marcus Shawcroft wrote:
> On 1 May 2015 at 14:56, Yvan Roux wrote:
>
>> 2015-05-01 Yvan Roux
>>
>> * configure.ac: Add --enable-fix-cortex-a53-843419 option.
>> * configure: Regenerate.
>> * config/aarch64/aarch64-elf-raw.h (CA53_ERR_843419_SP
On Sat, May 2, 2015 at 12:46 AM, Marc Glisse wrote:
> Hello,
>
> this patch tries to tighten a bit the range estimate for x%y. slp-perm-7.c
> started failing by vectorizing more than expected, I assumed it was a good
> thing and updated the test. I am less conservative than Jakub with division
> b
Hi,
This is a ping for: https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00772.html
Regtested with aarch64-linux-gnu on QEMU.
This patch has no regressions for aarch64_be-linux-gnu big-endian target too.
OK for the trunk?
Thanks.
Jiang jiji
On Fri, May 1, 2015 at 8:09 PM, Eric Botcazou wrote:
>> OK, how aggressive then? We could as well do the substitution for all
>> copies:
>>
>> /* For EXPAND_INITIALIZER try harder to get something simpler.
>>Otherwise, substitute copies on the RHS, this can propagate
>>const
On Mon, May 4, 2015 at 2:32 AM, David Edelsohn wrote:
> On Sat, May 2, 2015 at 6:04 AM, Eric Botcazou wrote:
>>> Why should GCC unnecessarily create stack frames to avoid
>>> compare-debug testcase failures?
>>
>> I'm not sure I understand the question... compare-debug failures are failures
>> (-
Hi!
On Thu, 30 Apr 2015 14:47:03 +0200, I wrote:
> Here is a patch, prepared by Jim Norris, to fix dg-shouldfail usage in
> OpenACC libgomp tests. It introduces two regressions (that is, makes the
> existing errors visible), which shall then be fixed later on:
> libgomp.oacc-c-c++-common/lib-3.c,
On Sat, 2 May 2015, Jakub Jelinek wrote:
> Hi!
>
> This is an attempt to fix the following testcase (reduced from gsoap)
> similarly how you've fixed another issue with r221795 other AAPCS
> regressions introduced with r221348 change.
> This patch passed bootstrap/regtest on
> {x86_64,i686,armv7h
On Thu, Apr 30, 2015 at 5:18 PM, H.J. Lu wrote:
> On Thu, Apr 30, 2015 at 8:15 AM, Ilya Tocar wrote:
>>> Hi,
>>>
>>> Looks like I missed some splits, which caused PR65915.
>>> Patch below fixes it.
>>> Ok for trunk?
>>>
>>> 2015-04-28 Ilya Tocar
>>>
>>> * config/i386/i386.md (define_spli
On Sun, May 03, 2015 at 10:59:46AM +0200, Andreas Schwab wrote:
> tbsaunde+...@tbsaunde.org writes:
>
> > +AC_DEFUN([gt_BITFIELD_TYPE_MATTERS],
> > +[
> > + AC_CACHE_CHECK([if the type of bitfields matters],
> > gt_cv_bitfield_type_matters,
> > + [
> > +AC_TRY_COMPILE(
> > + [struct fo
90 matches
Mail list logo
