On Thu, Oct 23, 2014 at 11:51 PM, Yangfei (Felix) wrote:
> Thanks for the explanation. I think I am clear about what you are thinking
> now.
> That's an interesting question. I am not sure about reason why GCC's reload
> cannot handle a doloop_end insn.
> I guess maybe the doloop_end pattern is
Thanks for the explanation. I think I am clear about what you are thinking now.
That's an interesting question. I am not sure about reason why GCC's reload
cannot handle a doloop_end insn.
I guess maybe the doloop_end pattern is special? I mean it's a branch insn in a
parallel form.
>
> On T
r216566 (r216568 for 4.9 branch) added %{fno-lto} to LINK_COMMAND_SPEC.
However the linker doesn't understand -fno-lto and errors out.
This causes LTO/PGO bootstrap to fail, because -fno-lto is used during
STAGEprofile.
Fixed by filtering out -fno-lto in collect2.c.
LTO/PGO bootstrapped and tested
On Thu, Oct 23, 2014 at 11:40 PM, Yangfei (Felix) wrote:
> 1. The original xtensa port never generates "loop" instruction at all.
> 2. A port doesn't need to implement hwloop_pattern_reg hook if it has no
> zero-cost loop instruction.
>
> Is that clear?
We are talking in circles. I understand ve
1. The original xtensa port never generates "loop" instruction at all.
2. A port doesn't need to implement hwloop_pattern_reg hook if it has no
zero-cost loop instruction.
Is that clear?
>
> I mean without your patch at all.
>
> On Thu, Oct 23, 2014 at 11:30 PM, Yangfei (Felix)
> wrote:
> >>
I mean without your patch at all.
On Thu, Oct 23, 2014 at 11:30 PM, Yangfei (Felix) wrote:
>>
>> On Thu, Oct 23, 2014 at 9:12 PM, Yangfei (Felix)
>> wrote:
>> >> Here the key point is we need a general purpose register for the "loop"
>> >> instruction.
>>
>> So the question to ask here is, "How
>
> On Thu, Oct 23, 2014 at 9:12 PM, Yangfei (Felix)
> wrote:
> >> Here the key point is we need a general purpose register for the "loop"
> >> instruction.
>
> So the question to ask here is, "How does this work today, without loop
> instructions?" Somehow--even when it has been spilled--a bra
From: Trevor Saunders
Hi,
do $subject, and cleanup for always 64 bit hwi.
bootstrapped + regtested x86_64-unknown-linux-gnu, ok?
Trev
gcc/ChangeLog:
2014-10-24 Trevor Saunders
* ipa-inline.c (edge_badness): Adjust.
(inline_small_functions): Likewise.
* predict.c
On Thu, Oct 23, 2014 at 9:12 PM, Yangfei (Felix) wrote:
>> Here the key point is we need a general purpose register for the "loop"
>> instruction.
So the question to ask here is, "How does this work today, without
loop instructions?" Somehow--even when it has been spilled--a branch
instruction ca
Hello!
2014-10-24 Martin Liska
* ipa-icf.c (sem_item_optimizer::parse_nonsingleton_classes): Guard
division by zero in dumps.
(sem_item_optimizer::merge_classes): Ditto.
Tested on alphaev68-linux-gnu, committed to mainline as obvious.
Uros.
diff --git a/gcc/ipa-icf.c b/gcc/ipa-ic
This patch to the Go frontend changes it to use the MPC library for
complex numbers, rather than using pairs of MPFR values. This is a
boilerplate change that lets us get rid of a bunch of code handling
complex constant multiplication and division. Bootstrapped and ran Go
testsuite on x86_64-unkn
> From: Hans-Peter Nilsson
> Date: Fri, 24 Oct 2014 06:32:06 +0200
> The libcpp configure checks are actually run with gcc which is
> bogus by itself, but apparently working. I guess the C vs. C++
> declaration etc. differences for libcpp are mostly hidden by
> using _GNU_SOURCE (through AC_USE_
A missing cast causes the compare value to be truncated, resulting in
spurious CAS failures.
The problem manifested in a new port I'm working on as a failure in test
gcc.dg/atomic/c11-atomic-exec-2.c, and I've confirmed that this patch
fixes it. I also verified that x86_64-unknown-linux still boo
> From: Richard Biener
> Date: Thu, 23 Oct 2014 10:47:43 +0200
> This adds a libcpp host module without NLS and ICONV support
> and properly links genmatch against the build libcpp instead of
> the host one.
>
> Bootstrap running on x86_64-unknown-linux-gnu (stage1 all-gcc
> finished fine).
>
>
> > On Tue, Oct 21, 2014 at 7:20 PM, Yangfei (Felix)
> wrote:
> > > If the tripcount spill issue is not handled in the pattern, ICE may
> > > happen then.
> > > Here reload is trying to spill pseudo 173, but a memory operand is
> > > not allowed
> > in zero_cost_loop_end pattern.
> > > And this i
On 10/22/14 21:35, Maxim Kuvyrkov wrote:
Hi,
For benchmarking and tuning of register-pressure scheduling I've made
the following simple patch to adjust effective number of registers
that scheduler has at its disposal. Do you think this would be
valuable for others to investigate performance pro
On 2014-10-22 11:29 PM, Maxim Kuvyrkov wrote:
On Oct 22, 2014, at 4:53 AM, Vladimir Makarov wrote:
On 10/20/2014 11:16 PM, Maxim Kuvyrkov wrote:
Hi,
This patch cleans up (removes) cached_first_cycle_multipass_dfa_lookahead and
cached_issue_rate.
These seem to be an artifact from the schedu
> > +__extension__ static __inline float64x2x4_t __attribute__
> > +((__always_inline__))
> > +vld4q_dup_f64 (const float64_t * __a) {
> > + float64x2x4_t ret;
> > + __builtin_aarch64_simd_xi __o;
> > + __o = __builtin_aarch64_ld4rv2df ((const __builtin_aarch64_simd_df
> > +*) __a);
> > + ret.v
The Go frontend currently only makes integer expressions using the
mpz_t type, which is awkward when building an expression for a
constant or other ordinary C integer. This patch adds a couple of
helper functions and changes the frontend to use them. Bootstrapped
and ran Go testsuite on x86_64-un
> On Tue, Oct 21, 2014 at 7:20 PM, Yangfei (Felix)
> wrote:
> > If the tripcount spill issue is not handled in the pattern, ICE may happen
> > then.
> > Here reload is trying to spill pseudo 173, but a memory operand is not
> > allowed
> in zero_cost_loop_end pattern.
> > And this is what I am
The attached change fixes a compile error caused by the last change to
pa.c.
Committed as obvious.
Dave
--
John David Anglin dave.ang...@bell.net
2014-10-23 John David Anglin
* config/pa/pa.c (pa_can_combine_p): Fix typo in last change.
Index: config/pa/pa.c
==
This patch fixes a typo in a comment in tree-vrp.c. Committed as obvious.
Ian
2014-10-23 Ian Lance Taylor
* tree-vrp.c (extract_range_from_assert): Fix typo in comment.
Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c (revisio
Hi Manuel,
Dodji Seketeli wrote:
Sorry, I forgot to make it clear that I have no power to approve the
line-map changes. I just gave my casual point view; so please take it
for what it is worth.
I am CC-ing Tom and Jason who can approve this.
And I have a minor nit, which I forgot in my origi
The target macro TARGET_HAS_F_SETLKW was removed from GCC back in 2005
(https://gcc.gnu.org/ml/gcc-patches/2005-07/msg00917.html). I
happened to notice a dreg in mep.h. After so long without a meaning,
it can't be necessary now. This patch removes it. Committed as
obvious.
Ian
2014-10-23 Ia
This patch to libbacktrace fixes the type returned by the backup
definition of backtrace_atomic_load_pointer for the case where
libbacktrace is compiled with neither the atomic nor the sync
functions available. This case does not arise in general but could
arise from other uses of the library, or
On 10/23/14 01:30, Jakub Jelinek wrote:
Hi!
As I wrote in the PR, vt_stack_adjustments can often compute wrong offsets,
because it never considers pops with autoinc addressing, which can lead
either to wrong debug info, or turning off -fvar-tracking altogether for
a function on which that issue
Richard Biener writes:
> This adds a libcpp host module without NLS and ICONV support
> and properly links genmatch against the build libcpp instead of
> the host one.
>
> Bootstrap running on x86_64-unknown-linux-gnu (stage1 all-gcc
> finished fine).
>
> Ok for trunk?
>
> Thanks,
> Richard.
>
> 2
Linux x86 bootstrap/make check passed.
Darwin x86 bootstrap passed configured with "--with-cpu=intel"
"--with-cpu=corei7" issue refers to PR63620.
On Fri, Oct 17, 2014 at 6:08 PM, Evgeny Stupachenko wrote:
> Hi,
>
> The patch fixes 1st fail in darwin bootstarp.
> When PIC register is pseudo we do
On 23/10/14 16:01 -0400, Jason Merrill wrote:
On 10/23/2014 03:59 PM, Jonathan Wakely wrote:
Tested x86_64-linux. OK for trunk?
Shouldn't there be another test that there's no warning if
-Wno-delete-incomplete or that it's an error with
-Werror=delete-incomplete? OK that way.
Oh yes, of c
Here is another patch to reduce the differences between the 32 bit MIPS
and 64 bit MIPS configuration. This patch combines the two case entries
in config.gcc into one entry so the header file list and other settings
don't have to be handled twice.
This patch should not change the build for any MI
On 10/23/2014 03:59 PM, Jonathan Wakely wrote:
Tested x86_64-linux. OK for trunk?
Shouldn't there be another test that there's no warning if
-Wno-delete-incomplete or that it's an error with
-Werror=delete-incomplete? OK that way.
Jason
Tested x86_64-linux. OK for trunk?
commit c3ce106375d17223bacaaccbf36bd15fcef3f560
Author: Jonathan Wakely
Date: Thu Oct 23 18:11:22 2014 +0100
gcc/cp:
PR c++/63619
* decl2.c (delete_sanity): Use OPT_Wdelete_incomplete in warning.
gcc/testsuite:
PR c++/63619
*
On Wed, Oct 22, 2014 at 4:43 AM, Rainer Orth
wrote:
> The gnu11 patch broke Solaris 10 and 11 bootstrap:
> has
>
> /*
> * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application
> * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, POSIX.1b,
> * and POSIX.1c applications
Sorry, I forgot to make it clear that I have no power to approve the
line-map changes. I just gave my casual point view; so please take it
for what it is worth.
I am CC-ing Tom and Jason who can approve this.
Cheers.
Dodji Seketeli writes:
> Hello Manuel,
>
> Manuel López-Ibáñez writes:
>
>
Fixes BISX.A bug. Committed.
2014-10-23 DJ Delorie
* config/msp430/msp430.c (msp430_print_operand): 'x' modifier is
independend of -mlarge.
* config/msp430/constraints.md (Ys): Update comment.
Index: config/msp430/constraints.md
==
On 10/22/2014 04:43 AM, Rainer Orth wrote:
> The gnu11 patch broke Solaris 10 and 11 bootstrap:
> has
>
> /*
> * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application
> * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, POSIX.1b,
> * and POSIX.1c applications. Likewis
On Wed, Oct 22, 2014 at 2:59 PM, Kirill Yukhin wrote:
> On 22 Oct 16:48, Kirill Yukhin wrote:
>> Hello,
>> This patch adds tests for new intrinsics.
>>
>> Bootstrapped.
>> AVX-512* tests on top of patch-set all pass
>> under simulator.
>>
>> Is it ok for trunk?
>>
>> gcc/
>> * testsuite/gcc.
On Wed, Oct 22, 2014 at 2:51 PM, Kirill Yukhin wrote:
> Hello,
> This patch introduces rest of intrinsics (compare).
>
> Bootstrapped.
> AVX-512* tests on top of patch-set all pass
> under simulator.
>
> Is it ok for trunk?
>
> gcc/
> * config/i386/avx512bwintrin.h: Add new intrinsics.
>
On Wed, Oct 22, 2014 at 2:37 PM, Kirill Yukhin wrote:
> Hello,
> This patch extends sse-* and avx-* tests
> which checks immediates/options.
>
> Bootstrapped.
> AVX-512* tests on top of patch-set all pass
> under simulator.
>
> Is it ok for trunk?
>
> gcc/
> * testsuite/g++.dg/other/i386-2
On Thu, Oct 23, 2014 at 8:39 AM, Pedro Alves wrote:
> On 10/23/2014 04:31 PM, Ian Taylor wrote:
>>
>> My patch was, of course, just building on the existing
>> unsupported_languages support. You are suggesting that we move that
>> support from the top level configure script to the language-specif
2014-10-23 16:33 GMT+04:00 Georg-Johann Lay :
> This no-op change fixed typos and restored coding rules as obvious like:
> spaces around operators, space before opening parentheses, wrapping long
> lines, indentation rules, trailing blanks, etc...
>
> http://gcc.gnu.org/r216592
>
>
> Johann
>
> gcc
2014-10-23 17:48 GMT+04:00 Georg-Johann Lay :
> This optimization makes most sign-extensions one instruction shorter in the
> case when the source register may be clobbered and the register numbers are
> different. Source and destination may overlap.
>
> Ok for trunk?
>
>
> Johann
>
> gcc/
>
On 10/22/14 21:36, Ian Taylor wrote:
This patch to the top level GCC configure script disables the go
languages on some systems where it is known to not work. Bootstrapped
on x86_64-unknown-gnu-linux.
OK for mainline?
Ian
2014-10-22 Ian Lance Taylor
* configure.ac: Disable the Go frontend
On Wed, Oct 22, 2014 at 2:43 PM, Kirill Yukhin wrote:
> Hello,
> This patch introduces necessary AVX-512* intrinsics headers.
>
> Bootstrapped.
> AVX-512* tests on top of patch-set all pass
> under simulator.
>
> Is it ok for trunk?
>
> gcc/
> * config/i386/avx512bwintrin.h: New.
>
On 10/23/14 01:09, Jan Beulich wrote:
On 23.10.14 at 08:50, wrote:
On Thu, Oct 23, 2014 at 07:30:27AM +0100, Jan Beulich wrote:
Function (or more narrow) scope static variables (as well as others not
placed on the stack) should also not have any effect on the stack
alignment. I noticed the iss
On Wed, Oct 22, 2014 at 2:58 PM, Kirill Yukhin wrote:
> Hello,
> This patch fixes kmov* insn generation
> and adds memory alternative to `movqi_internal'
> pattern
> Reg-test included.
>
> Bootstrapped.
> AVX-512* tests on top of patch-set all pass
> under simulator.
>
> Is it ok for trunk?
>
> gc
On Wed, Oct 22, 2014 at 2:28 PM, Kirill Yukhin wrote:
> Hello,
> This tiny patch adds couple of missing immediate checks.
>
> Bootstrapped.
> AVX-512* tests on top of patch-set all pass
> under simulator.
>
> Is it ok for trunk?
>
> gcc/
> * config/i386/i386.c (ix86_expand_args_builtin): H
On Wed, Oct 22, 2014 at 2:19 PM, Kirill Yukhin wrote:
> Hello,
> This patch adds built-ins for scatter insns.
>
> Bootstrapped.
> AVX-512* tests on top of patch-set all pass
> under simulator.
>
> Is it ok for trunk?
>
> gcc/
> * config/i386/i386.c
> (ix86_init_mmx_sse_builtins):
>
On 23 October 2014 11:14, Marcus Shawcroft wrote:
> On 8 October 2014 18:27, wrote:
>
>> +#define __LD2_LANE_FUNC(intype, vectype, largetype, ptrtype, \
>
> Just above the insertion point in arm-neon.h is the comment:
>
> /* Start of temporary inline asm for vldn, vstn and friends.
On Wed, Oct 22, 2014 at 2:17 PM, Kirill Yukhin wrote:
> Hello,
> This patch introduces built-ins for gather insns.
>
> Bootstrapped.
> AVX-512* tests on top of patch-set all pass
> under simulator.
>
> Is it ok for trunk?
>
> gcc/
> * config/i386/i386.c (ix86_builtins): Add
> IX86_BUILTIN
On Tue, Oct 21, 2014 at 7:20 PM, Yangfei (Felix) wrote:
> If the tripcount spill issue is not handled in the pattern, ICE may happen
> then.
> Here reload is trying to spill pseudo 173, but a memory operand is not
> allowed in zero_cost_loop_end pattern.
> And this is what I am trying to solve.
On 10/23/2014 04:03 PM, Uros Bizjak wrote:
On Thu, Oct 23, 2014 at 3:54 PM, Uros Bizjak wrote:
Ok, will try that. Still no idea why Linux/x86 and Solaris/x86 are
different here.
Why do you think so? I certainly have:
FAIL: gcc.dg/ipa/ipa-icf-21.c (test for excess errors)
UNRESOLVED: gcc.dg
Alan Lawrence writes:
> Mmmm, I've made a few attempts at filtering according to LP64 and ILP32,
> but not managed to get anything working so far (that is, I've ended up with
> the test not being executed on platforms where it should)ah, I see now
> where I've been going wrong, patch attached
Committed to trunk.
commit 65b21ceb68ef845874f79555cd51d7e54e69340f
Author: Jonathan Wakely
Date: Thu Oct 23 17:54:34 2014 +0100
* doc/xml/manual/status_cxx2011.xml: Update status.
* doc/xml/manual/status_cxx2014.xml: Update TS status.
diff --git a/libstdc++-v3/doc/xml/manual/status
Mmmm, I've made a few attempts at filtering according to LP64 and ILP32, but not
managed to get anything working so far (that is, I've ended up with the test not
being executed on platforms where it should)ah, I see now where I've been
going wrong, patch attached.
The original intent was p
On Thu, 23 Oct 2014, Marek Polacek wrote:
> At present, we print the "inline function ... declared but never
> defined" warning twice. The reason for that is that this warning
> is being printed in pop_scope, which is called when popping file
> scope (c_common_parse_file->pop_file_scope), and whe
On 2014.10.22 at 13:57 +0200, Tobias Burnus wrote:
> I intent to commit the following patch this evening, which was
> pre-proved for 4.9/trunk by Richard in the PR.
> However, I still need to do the bootstrapping and regtesting.
This breaks bootstrap-lto:
...
configure: error: Link tests are not a
This adds:
std::notify_all_at_thread_exit()
std::promise<>::set_value_at_thread_exit()
std::promise<>::set_exception_at_thread_exit()
std::packaged_task<>::make_ready_at_thread_exit()
There's a linked list of callbacks that run after TLS destructors
(called by a pthread_key_create destructor)
On 22 Oct 11:22, Jakub Jelinek wrote:
> On Tue, Oct 21, 2014 at 09:24:13PM +0400, Ilya Verbin wrote:
> > + mic_lib_path_new = (char *) malloc ((mic_lib_path ? strlen
> > (mic_lib_path) : 0)
> > + + strlen (ld_lib_path) + 2);
>
> malloc can fail, SIGSEGV in respons
On 10/23/2014 04:31 PM, Ian Taylor wrote:
> On Thu, Oct 23, 2014 at 8:27 AM, Pedro Alves wrote:
>>
>> I think it'd be better if knowledge specific to subdirs was pushed down to
>> the subdirs, rather than being kept in the top level, in the direction
>> of how we disable libatomic, libsanitizer, e
> Jakub Jelinek writes:
>
> > On Thu, Oct 23, 2014 at 11:35:44AM +0200, Rainer Orth wrote:
> >> > The testcase is clearly i?86/x86_64 specific, so it must be guarded with
> >> > { target i?86-*-* x86_64-*-* }, and as it is a compile time test, no need
> >>
> >> Right, that's what my patch alread
On Thu, Oct 23, 2014 at 8:27 AM, Pedro Alves wrote:
>
> I think it'd be better if knowledge specific to subdirs was pushed down to
> the subdirs, rather than being kept in the top level, in the direction
> of how we disable libatomic, libsanitizer, etc. That is, by sourcing
> something in the sub
On 10/23/2014 04:36 AM, Ian Taylor wrote:
> This patch to the top level GCC configure script disables the go
> languages on some systems where it is known to not work. Bootstrapped
> on x86_64-unknown-gnu-linux.
>
> OK for mainline?
>
> Ian
>
> 2014-10-22 Ian Lance Taylor
>
> * configure.ac
On Thu, Oct 23, 2014 at 04:31:36PM +0200, Richard Biener wrote:
>
> Final try for today.
>
> Richard.
>
> Index: gcc/Makefile.in
> ===
> --- gcc/Makefile.in (revision 216590)
> +++ gcc/Makefile.in (working copy)
> @@ -981,7 +981
On Thu, 23 Oct 2014, Richard Biener wrote:
>
> Final try for today.
And this may work as well and is slightly simpler.
Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 216590)
+++ gcc/Makefile.in (working copy)
@@ -
Final try for today.
Richard.
Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 216590)
+++ gcc/Makefile.in (working copy)
@@ -981,7 +981,15 @@ else
LIBIBERTY = ../libiberty/libiberty.a
BUILD_LIBIBERTY = $(build_lib
"Jeff Law" :
> On 10/21/14 12:21, jb...@gmx.de wrote:
> > "Jeff Law" :
> >> On 10/21/14 16:13, Haswell wrote:
> >>> The additional source must have the same requirement
> >>> crossmodule-indircall-1.c has.
> >>>
> >>> * crossmodule-indircall-1a.c: Add missing requirement.
> >> Why? When used b
On Thu, 23 Oct 2014, Richard Biener wrote:
> On Thu, 23 Oct 2014, Richard Biener wrote:
>
> > On Thu, 23 Oct 2014, Rainer Orth wrote:
> >
> > > Richard Biener writes:
> > >
> > > > This adds a libcpp host module without NLS and ICONV support
> > > > and properly links genmatch against the buil
On Thu, 23 Oct 2014, Richard Biener wrote:
> On Thu, 23 Oct 2014, Rainer Orth wrote:
>
> > Richard Biener writes:
> >
> > > This adds a libcpp host module without NLS and ICONV support
> > > and properly links genmatch against the build libcpp instead of
> > > the host one.
> > >
> > > Bootstra
Index: gcc/config/aarch64/arm_neon.h
===
--- gcc/config/aarch64/arm_neon.h (revision 216558)
+++ gcc/config/aarch64/arm_neon.h (working copy)
@@ -11765,46 +11765,271 @@ __STRUCTN (poly, 8, 4)
__STRUCTN (float, 64, 4)
#
On Thu, Oct 23, 2014 at 3:54 PM, Uros Bizjak wrote:
>>> Ok, will try that. Still no idea why Linux/x86 and Solaris/x86 are
>>> different here.
>>
>> Why do you think so? I certainly have:
>> FAIL: gcc.dg/ipa/ipa-icf-21.c (test for excess errors)
>> UNRESOLVED: gcc.dg/ipa/ipa-icf-21.c scan-ipa-d
Hello!
>> Ok, will try that. Still no idea why Linux/x86 and Solaris/x86 are
>> different here.
>
> Why do you think so? I certainly have:
> FAIL: gcc.dg/ipa/ipa-icf-21.c (test for excess errors)
> UNRESOLVED: gcc.dg/ipa/ipa-icf-21.c scan-ipa-dump icf "Equal symbols: 1"
> UNRESOLVED: gcc.dg/ipa/
This optimization makes most sign-extensions one instruction shorter in the
case when the source register may be clobbered and the register numbers are
different. Source and destination may overlap.
Ok for trunk?
Johann
gcc/
* config/avr/avr.md (extendqihi2, extendqipsi2, extendqisi
The following makes sure to convert the correct argument, not the
one we already converted. Currently we end up folding
ptr-type - integer-type. Oops. Fails spectacularly on
match-and-simplify where this is the first strip-nops
missed-optimization (on bogus input, that is).
I'm considering th
On Thu, Oct 23, 2014 at 2:50 PM, Kirill Yukhin wrote:
> Hello Uroš,
> On 20 Oct 17:41, Kirill Yukhin wrote:
>> This patch adds (almost) all built-ins
> This is second, target dependent, part of the initial patch.
>
> ChangeLog is the same as in intial mail - tree* changes.
>
> Is it ok for trunk?
Jakub Jelinek writes:
> On Thu, Oct 23, 2014 at 02:58:06PM +0200, Rainer Orth wrote:
>> Unfortunately, I see some problems with those tests on Solaris:
>>
>> * On Solaris/x86, I get
>>
>> FAIL: gcc.dg/pr63594-2.c execution test
>>
>> for 32-bit. Any particular reason to restrict -mno-mmx to
Evgeny Stupachenko writes:
> Reattached.
>
> On Mon, Oct 13, 2014 at 8:22 PM, Uros Bizjak wrote:
>> On Mon, Oct 13, 2014 at 4:53 PM, Evgeny Stupachenko
>> wrote:
>>
>>> ChangeLog for testsuite:
>>>
>>> 2014-10-13 Evgeny Stupachenko
>>>
>>> PR target/8340
>>> PR middle-end/476
This is a second attempt - it fixes the bugs in the previous one
and handles falling back or not separately for the incoming arguments.
What we handle too conservatively right now is non-captured leafs
and captured expressions that are substituted into the result.
Both result in the incoming argu
On match-and-simplify branch I run into a recursion folding
(bool_var & 1) == 0
via !(bool_var & 1) to
(bool_var & 1) == 0
The appearant recursion prevention (well, not documented as such)
in fold_truth_not_expr doesn't work because we still fold its
result via the various fold_convert calls
On Thu, Oct 23, 2014 at 02:58:06PM +0200, Rainer Orth wrote:
> Unfortunately, I see some problems with those tests on Solaris:
>
> * On Solaris/x86, I get
>
> FAIL: gcc.dg/pr63594-2.c execution test
>
> for 32-bit. Any particular reason to restrict -mno-mmx to Linux/x86?
> Manually building
Andreas Schwab writes:
> Alan Lawrence writes:
>
>> diff --git a/gcc/testsuite/gcc.dg/combine_ashiftrt_1.c
>> b/gcc/testsuite/gcc.dg/combine_ashiftrt_1.c
>> new file mode 100644
>> index
>> ..90e64fd10dc358f10ad03a90041605bc3ccb7011
>> --- /dev/null
>> +++
On Thu, 23 Oct 2014, Rainer Orth wrote:
> Richard Biener writes:
>
> > This adds a libcpp host module without NLS and ICONV support
> > and properly links genmatch against the build libcpp instead of
> > the host one.
> >
> > Bootstrap running on x86_64-unknown-linux-gnu (stage1 all-gcc
> > fini
On Thu, Oct 23, 2014 at 02:34:04PM +0200, Marek Polacek wrote:
> The issue here was that we were diagnosing an artificial check
> that we created within the scope of shift instrumentation. In
> other words, for shifts we create something like
> (unsigned) A >> (B - C) and signed-integer-overflow t
Hi Jakub,
> This patch fixes a bunch of recent regressions:
> FAIL: gcc.target/i386/avx-1.c (internal compiler error)
> FAIL: gcc.target/i386/avx-1.c (test for excess errors)
> FAIL: gcc.target/i386/avx-2.c (internal compiler error)
> FAIL: gcc.target/i386/avx-2.c (test for excess errors)
> FAIL:
On Thu, Oct 23, 2014 at 02:46:52PM +0200, Jakub Jelinek wrote:
> Ok. Can you please queue it for 4.9 branch too, after 4.9.2 is released?
> There is no -f*sanitize-recover* support, but it can be supposedly left out
> from dg-options for the branch.
Sure.
Marek
Richard Biener writes:
> This adds a libcpp host module without NLS and ICONV support
> and properly links genmatch against the build libcpp instead of
> the host one.
>
> Bootstrap running on x86_64-unknown-linux-gnu (stage1 all-gcc
> finished fine).
Unfortunately, this doesn't work on i386-pc-
This no-op change fixed typos and restored coding rules as obvious like:
spaces around operators, space before opening parentheses, wrapping long lines,
indentation rules, trailing blanks, etc...
http://gcc.gnu.org/r216592
Johann
gcc/
* config/avr/avr.c: Fix GNU coding rules and typo
The issue here was that we were diagnosing an artificial check
that we created within the scope of shift instrumentation. In
other words, for shifts we create something like
(unsigned) A >> (B - C) and signed-integer-overflow triggered
on that subtraction. Fixed by making the subtraction work on
Jakub Jelinek writes:
> On Thu, Oct 23, 2014 at 11:35:44AM +0200, Rainer Orth wrote:
>> > The testcase is clearly i?86/x86_64 specific, so it must be guarded with
>> > { target i?86-*-* x86_64-*-* }, and as it is a compile time test, no need
>>
>> Right, that's what my patch already does.
>>
>>
On Thu, Oct 23, 2014 at 01:33:18PM +0200, Jakub Jelinek wrote:
> > I combined both patches and run regression tests on x86_64-linux-pc.
> > Ready for trunk?
>
> With proper ChangeLog entry yes.
Actually, Rainer seems to have committed everything already.
Jakub
On 10/19/2014 09:50 AM, Andreas Schwab wrote:
Martin Liška writes:
diff --git a/gcc/testsuite/gcc.dg/ipa/ipa-icf-21.c
b/gcc/testsuite/gcc.dg/ipa/ipa-icf-21.c
new file mode 100644
index 000..7358e43
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/ipa/ipa-icf-21.c
@@ -0,0 +1,27 @@
+/* { dg-do comp
Jakub Jelinek writes:
>> The former can be cured by adding -Wno-psabi to dg-options, but I've no
>> idea what to do about the latter, especially since it doesn't occur on
>> i386-pc-solaris2.11.
>
> The testcase is clearly i?86/x86_64 specific, so it must be guarded with
> { target i?86-*-* x86_6
On Thu, Oct 23, 2014 at 01:31:53PM +0200, Martin Liška wrote:
> On 10/23/2014 11:38 AM, Jakub Jelinek wrote:
> >On Thu, Oct 23, 2014 at 11:35:44AM +0200, Rainer Orth wrote:
> >>>The testcase is clearly i?86/x86_64 specific, so it must be guarded with
> >>>{ target i?86-*-* x86_64-*-* }, and as it i
On 10/23/2014 11:38 AM, Jakub Jelinek wrote:
On Thu, Oct 23, 2014 at 11:35:44AM +0200, Rainer Orth wrote:
The testcase is clearly i?86/x86_64 specific, so it must be guarded with
{ target i?86-*-* x86_64-*-* }, and as it is a compile time test, no need
Right, that's what my patch already does.
On 09 Oct 08:25, H.J. Lu wrote:
> On Thu, Oct 9, 2014 at 1:37 AM, Uros Bizjak wrote:
> > On Thu, Oct 9, 2014 at 10:25 AM, Kirill Yukhin
> > wrote:
> >> On 08 Oct 23:02, Petr Murzin wrote:
> >>> Hi,
> >>> I have measured performance impact on Haswell platform according to this
> >>> input:
> >>>
At present, we print the "inline function ... declared but never
defined" warning twice. The reason for that is that this warning
is being printed in pop_scope, which is called when popping file
scope (c_common_parse_file->pop_file_scope), and when popping
external scope (c_write_global_declaratio
On Thu, Oct 23, 2014 at 9:30 AM, Jakub Jelinek wrote:
> Hi!
>
> As I wrote in the PR, vt_stack_adjustments can often compute wrong offsets,
> because it never considers pops with autoinc addressing, which can lead
> either to wrong debug info, or turning off -fvar-tracking altogether for
> a funct
Hello Manuel,
Manuel López-Ibáñez writes:
> Dodji, are the linemap_asserts() appropriate?
Yes they are. I have some additional comments though.
> libcpp/ChangeLog:
>
> 2014-10-16 Manuel López-Ibáñez
>
> PR fortran/44054
> * include/line-map.h (linemap_position_for_loc_and_offset):
On 10/23/2014 02:38 PM, Jakub Jelinek wrote:
> On Thu, Oct 23, 2014 at 02:33:42PM +0400, Yury Gribov wrote:
>> Actually this is a historical artifact. If inlining proves to be
>> significantly faster, they may want to switch.
>
> Ok.
>
>>> So, at that point you can include your ugly hacks in __a
On Wed, Oct 22, 2014 at 11:51:32AM +0400, Kirill Yukhin wrote:
> gcc/
> * tree-core.h (tree_var_decl): Extend `function_code' field
> by one bit, move `regdecl_flag' field to ...
> (tree_decl_with_vis): Here.
> * tree.h (DECL_STATIC_CHAIN): Update struct name.
>
>
>
1 - 100 of 143 matches
Mail list logo
