Thomas Schwinge wrote:
On Sat, 26 Jul 2014 01:47:02 +0200, Tobias Burnus wrote:
[...]
2014-07-26 Tobias Burnus
* gfortran.dg/sizeof_4.f90: New.
[...]
I noticed that the sizeof_4.f90 test case has not been checked in,
probably just forgot to svn add the file?
I have now committed
Uros Bizjak wrote:
> -/* { dg-options "-mieee" { target sh*-*-* alpha*-*-* } } */
> +/* { dg-options "-w -mieee" { target sh*-*-* alpha*-*-* } } */
> /* { dg-skip-if "No Inf/NaN support" { spu-*-* } "*" "" } */
>
> Please use /* { dg-add-options ieee } */ directive here. There is
> another one p
Hello!
> It looks that alpha has the similar issue:
> https://gcc.gnu.org/ml/gcc-testresults/2014-08/msg02660.html
>
> alpha and sh redefine dg-options to "-mieee" in the test case
> instead of the default dg-options "-w" and get the above warning.
> The patch below tweaks the test to fix it. Per
On Tue, Sep 02, 2014 at 09:47:15AM -0400, David Edelsohn wrote:
> Alan,
>
> Any feedback?
It is just papering over the real bug(s), of course, so I'd be
inclined to say this doesn't belong on trunk.
If you take a look at the assembly that is failing, you find gcc is
trying to output a location e
Oleg Endo wrote:
> -mieee should be the default on sh* and thus can be removed from the
> dg-options line, or is it not? If -mieee is still needed (for alpha) maybe
> it's better to use dg-additional-options instead?
Sure. The attached is a revised one.
Regards,
kaz
--
* gcc.
Hi,
On Sep 3, 2014, at 2:42 AM, Kaz Kojima wrote:
> Hi,
>
> gcc.c-torture/execute/pr39228.c fails with "(test for excess errors)"
> on SH for recent revisions. My gcc.log says:
>
> gcc.c-torture/execute/pr39228.c:20:43: warning: always_inline function might
> not be inlinable [-Wattributes]
On Tue, Sep 2, 2014 at 9:40 PM, Segher Boessenkool
wrote:
> On Tue, Sep 02, 2014 at 02:10:32PM +0200, Ulrich Weigand wrote:
>> In any case, this test in can_combine_p rejects a combination for *two*
>> different issues. One is the earlyclobber problem, which is what that
>> 2004 thread was about,
On 08/23/14 10:33, Nathan Sidwell wrote:
Hi,
this patch fixes a defect Jan found with firefox and its shared objects. We
were inadvertently calling an externally visible and overridable symbol, rather
than the local shared object's instance. This led to strangely sparse gcov
results.
I've take
Hi,
gcc.c-torture/execute/pr39228.c fails with "(test for excess errors)"
on SH for recent revisions. My gcc.log says:
gcc.c-torture/execute/pr39228.c:20:43: warning: always_inline function might
not be inlinable [-Wattributes]
...
It looks that alpha has the similar issue:
https://gcc.gnu.org
From: Trevor Saunders
Hi,
$subject again
bootstrapped + regtested on x86_64-unknown-linux-gnu, and run through
config-list.mk. Will commit it shortly as preapproved by Jeff in
http://gcc.gnu.org/ml/gcc-patches/2014-08/msg01310.html
Trev
gcc/ChangeLog:
* cfgexpand.c (label_rtx_for_bb
From: Trevor Saunders
Hi,
$subject
bootstrapped + regtested on x86_64-unknown-linux-gnu, and run through
config-list.mk. Will commit it shortly as preapproved by Jeff in
http://gcc.gnu.org/ml/gcc-patches/2014-08/msg01310.html
Trev
gcc/
* asan.c, cfgexpand.c, config/alpha/alpha.md, c
On Tue, Sep 2, 2014 at 3:29 PM, H.J. Lu wrote:
> On Thu, May 8, 2014 at 11:19 AM, Marek Polacek wrote:
>> On Wed, May 07, 2014 at 11:31:38AM -0700, H.J. Lu wrote:
>>> > OK, though I'm not sure if the "lp64" conditions are right in the testcase
>>>
>>> It should be !ia32 instead of lp64.
>>
>> Ok,
On Thu, May 8, 2014 at 11:19 AM, Marek Polacek wrote:
> On Wed, May 07, 2014 at 11:31:38AM -0700, H.J. Lu wrote:
>> > OK, though I'm not sure if the "lp64" conditions are right in the testcase
>>
>> It should be !ia32 instead of lp64.
>
> Ok, I changed lp64 to ! { ia32 } and committed the patch no
Ping.
On 19-08-2014 13:54, Adhemerval Zanella wrote:
> Ping.
>
> On 06-08-2014 17:21, Adhemerval Zanella wrote:
>> On 01-08-2014 12:31, Joseph S. Myers wrote:
>>> On Thu, 31 Jul 2014, David Edelsohn wrote:
>>>
Thanks for implementing the FENV support. The patch generally looks
good to
This patch makes the build of gcov-tool configurable. It checks if
ftw.h is available. For mingw build, it provides ftw functionality by
using FindFirstFile/FindNextFile/FindClose API.
Tested with and without --disable-gcov-tool.
Thanks,
-Rong
2014-09-02 Rong Xu
* gcc/Makefile.in: Ma
On 09/02/2014 01:59 AM, Matthew Fortune wrote:
>> > gcc/
>> >* target.def (TARGET_DWARF_FRAME_REG_MODE): New target hook.
>> >* targhooks.c (default_dwarf_frame_reg_mode): New function.
>> >* targhooks.h (default_dwarf_frame_reg_mode): New prototype.
>> >* doc/tm.texi.in (TARGET_DWA
On 06/20/2014 05:17 PM, Sriraman Tallam wrote:
> Index: config/i386/i386.c
> ===
> --- config/i386/i386.c(revision 211826)
> +++ config/i386/i386.c(working copy)
> @@ -12691,7 +12691,9 @@ legitimate_pic_address_disp_p (
Am 02.09.2014 17:32, schrieb Tobias Burnus:
>
> Marek Polacek wrote:
>> This patch fixes the last two spots where -Wlogical-not-parentheses
>> warns. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62270#c3
>> if you want more info about the changes.
>>
>> Bootstrapped/regtested on x86_64-linux,
It turns out that the REG_EQUAL note is removed on a hoisted
instruction (relevant code is in dead_or_predicable in ifcvt.c) if the
source of the move instruction is not a function invariant. In this
case, the source is a function invariant (constant) and so that
doesn't kick in. I don't understand
Several targets define a function like i386's get_some_local_dynamic_name.
The function looks through the current output function and returns the first
(arbitrary) local-dynamic symbol that it finds. The result can be used in
a call to __tls_get_addr, since all local-dynamic symbols have the same
Ping.
On Fri, Jul 11, 2014 at 10:42 AM, Sriraman Tallam wrote:
> Ping.
>
> On Thu, Jun 26, 2014 at 10:54 AM, Sriraman Tallam wrote:
>> Hi Uros,
>>
>>Could you please review this patch?
>>
>> Thanks
>> Sri
>>
>> On Fri, Jun 20, 2014 at 5:17 PM, Sriraman Tallam wrote:
>>> Patch Updated.
>>>
>
Ping.
On Wed, Aug 6, 2014 at 2:42 PM, Sriraman Tallam wrote:
> Hi,
>
> Just wondering if you got a chance to look at this?
>
> Sri
>
> On Tue, Jul 8, 2014 at 10:45 AM, Sriraman Tallam wrote:
>> On Tue, Jul 8, 2014 at 10:38 AM, Sriraman Tallam wrote:
>>> On Mon, Jul 7, 2014 at 11:48 AM, Jan Hu
As Jeff suggested here:
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00390.html
this patch documents that the first operand to an RTX_AUTOINC
is the automodified register.
Tested on x86_64-linux-gnu. OK to install?
Thanks,
Richard
gcc/
* doc/rtl.texi (RTX_AUTOINC): Document that the f
> I suspect the bulk of them currently are coming from the safe_as_a
> calls within NEXT_INSN and PREV_INSN; do you happen to have
> information handy on that?
Yes that's right:
- 1.03% lto1[.] bool
is_a_helper::test(rtx_def*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62174
The typespecs for Cray pointees are overwritten by the typespecs of
components with the same name which are declared later.
This problem was introduced with Cray pointer support in 4.1.0 and is
confirmed up through trunk (5.0).
Here is a propose
Hi Bernd,
This patch allows to compile binaries with offloading without passing -flto
option, and
w/o performing link-time optimizations of the host code.
How it works:
1. If there is at least one function or global variable to offload, gcc sets
flag_generate_lto.
This enables writing the byte
Hi Tobias!
On Sat, 26 Jul 2014 01:47:02 +0200, Tobias Burnus wrote:
> 2014-07-26 Tobias Burnus
>
> * check.c (gfc_check_sizeof): Permit for assumed type if and
> only if it has an array descriptor.
> * intrinsic.c (do_ts29113_check): Permit SIZEOF.
> (add_functions): S
On Tue, 2 Sep 2014, Marek Polacek wrote:
> PR62294 reports that 4.9 does not emit an "incompatible pointer type"
> warning in certain scenario. I unknowingly broke this in r207335, and
> then fixed it in r210980, which is a follow-up to the former. But 4.9
> doesn't have the latter. This patch
> Or we simply should make -finline work at -O0 (I suppose it might already
> work?) and use it.
Yes that's probably better. There are more hot inlines in the stage 1 profile
(like wi::storage_ref or vec::length)
I suspect with the ongoing C++'ification that will get worse.
-Andi
--
a...@linux.
On 20 August 2014 10:31, Alan Lawrence wrote:
> The only reference is in a comment.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-builtins.c (enum aarch64_type_qualifiers):
> Remove qualifier_const_pointer, update comment.
OK /M
On 20 August 2014 10:25, Alan Lawrence wrote:
> The SIMD-register variant is miscategorized as "alu_reg" despite not using
> any ALU registers, and should be "neon_add" for e.g. scheduling.
>
> Tested with check-gcc and check-g++ on aarch64-none-elf and
> aarch64_be-none-elf.
>
> gcc/ChangeLog:
>
On 20 August 2014 10:20, Alan Lawrence wrote:
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-builtins.c (aarch64_simd_expand_args):
> Replace
> varargs with pointer parameter.
> (aarch64_simd_expand_builtin): pass pointer into previous.
OK /Marcus
On 19 August 2014 18:02, Alan Lawrence wrote:
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-simd.md (aarch64_rbit): New pattern.
> * config/aarch64/aarch64-simd-builtins.def (rbit): New builtin.
>
> * config/aarch64/arm_neon.h (vrbit_s8, vrbit_u8, vrbitq_s8,
> vrbitq_u8):
On 12 August 2014 11:12, Alan Lawrence wrote:
> This patch replaces the current inline assembler for the vget_high
> intrinsics in arm_neon.h with a sequence of other calls, in a similar
> fashion to vget_low. Unlike the assembler, these are all transparent to the
> front-end, so should enable bet
On 09/02/2014 08:51 AM, Ramana Radhakrishnan wrote:
> The ADDV instruction isn't available on the AArch32 side IIRC. Given that
> situation there is no intrinsic for ADDV on the AArch32 side which is why this
> doesn't exist in the AArch32 version of arm_neon.h :(
Whoops, yes indeed. I clearly mi
> When I ran Asan test on Asan-bootstrapped GCC, some of them fail with
> memory leaks into GCC, even if Lsan is disabled. This caused by slightly
> wrong logic in saving/restoring env variables functionality in
> gcc-dg.exp (some tests override ASAN_OPTIONS and this env variable isn't
> restored
On 02/09/14 16:47, Richard Henderson wrote:
On 09/02/2014 08:34 AM, Kyrill Tkachov wrote:
2014-09-02 Kyrylo Tkachov
* config/aarch64/predicates.md (aarch64_comparison_operation):
New special predicate.
* config/aarch64/aarch64.md (*csinc2_insn): Use
aarch64_comparison_op
Now that PR61271 and PR62270 have been fixed, we can enable
-Wlogical-not-parentheses by -Wall. I think this warning proved
useful.
Bootstrapped/regtested on x86_64-linux and ppc64-linux, ok for trunk?
2014-08-26 Marek Polacek
* doc/invoke.texi: Document that -Wlogical-not-parenthese
On 02/09/14 16:28, Richard Henderson wrote:
Is it intentional or not that AArch64 does not define __ARM_NEON__?
Yes I remember so, __ARM_NEON__ is not ACLE compatible so we haven't
defined it for AArch64 - on AArch32 and AArch64 we now have __ARM_NEON
defined so that's the macro to be used.
On 02/09/14 16:34, Kyrill Tkachov wrote:
Hi all,
In continuation of patch [1/2]...
We can use the vector forms of the vcvt{a,p,m} instructions to vectorise
the l{round, ceil, floor}f functions.
Builtins are added and the TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION
implementation is updated to
On 02/09/14 16:34, Kyrill Tkachov wrote:
Hi all,
This patch implements the {lceil, lfloor, lround}si{sf, df}2 optabs in a
similar way to fcvt in aarch64. We use the new ARMv8 FP convert with
rounding instructions vcvt{a,p,m} for that.
Bootstrapped and tested on arm-none-linux-gnueabihf.
Ok f
On Sep 2, 2014, at 3:28 AM, Hans-Peter Nilsson
wrote:
> In a native x86_64-linux toolchain in which
> eh-table-registration is done explicitly (i.e. dl_iterate_phdr
> and PT_GNU_EH_FRAME is *not* assumed, as that eliminates the
> issue), the memory overhead for exception-initialization goes
> bey
On 09/02/2014 08:34 AM, Kyrill Tkachov wrote:
> 2014-09-02 Kyrylo Tkachov
>
> * config/aarch64/predicates.md (aarch64_comparison_operation):
> New special predicate.
> * config/aarch64/aarch64.md (*csinc2_insn): Use
> aarch64_comparison_operation instead of matching an operator.
On 09/02/2014 11:07 AM, Paolo Carlini wrote:
Anyway, what about the below? Certainly works for the tests which we
have got.
Hmm. This is definitely an improvement, as it allows a subset of
a non-volatile glvalue of literal type that refers to a non-volatile
object whose lifetime began within
Hi all,
This patch implements the {lceil, lfloor, lround}si{sf, df}2 optabs in a
similar way to fcvt in aarch64. We use the new ARMv8 FP convert with
rounding instructions vcvt{a,p,m} for that.
Bootstrapped and tested on arm-none-linux-gnueabihf.
Ok for trunk?
Thanks,
Kyrill
2014-09-02 Ky
Hi all,
In continuation of patch [1/2]...
We can use the vector forms of the vcvt{a,p,m} instructions to vectorise
the l{round, ceil, floor}f functions.
Builtins are added and the TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION
implementation is updated to wire up the vectorised forms of these
fu
Hi all,
The store_minmaxsi produces a cmp + ite + 2 conditional stores and is
thus inappropriate when the ARMv8-A IT block rules are in place.
Previously we had disabled it for speed optimisations, but it should be
disabled completely when -mrestrict-it is in effect.
Ok for trunk and 4.9?
T
Hi Richard,
Sorry for the delay.
On 19/08/14 17:09, Richard Henderson wrote:
(define_special_predicate "cc_register_zero"
(match_code "reg")
{
return (REGNO (op) == CC_REGNUM
&& (GET_MODE (op) == CCmode
|| GET_MODE (op) == CC_Zmode
|| GET_MODE (op)
Hi all,
Following the transition to UAL I noticed that the %N output modifier
doesn't really work. It calls fp_const_from_val to get the VFP encoding
from a real value, but fp_const_from_val only supports the floating
point zero constant and ICEs for all other values, making it useless for
pr
Hi all,
I noticed for some reason that these tests don't properly dump the
vectoriser pass before scanning, but it doesn't show up because the
corresponding target predicate in the scan-tree-dump directive was never
true on arm!
I think these tests were initially supposed to go somewhere in th
Marek Polacek wrote:
> This patch fixes the last two spots where -Wlogical-not-parentheses
> warns. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62270#c3
> if you want more info about the changes.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
Looks good to me. Thanks for the patc
Is it intentional or not that AArch64 does not define __ARM_NEON__?
Otherwise, here's a better way to fold the test bits. AArch64 of
course does not have dN+1 overlap the high part of the qM register,
like AArch32, so the current
l = vpadd_u8 (vget_low_u8 (t), vget_high_u8 (t));
implie
On 19 August 2014 14:43, Alan Lawrence wrote:
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-builtins.c (aarch64_fold_builtin): Remove
> code
> handling cmge, cmgt, cmeq, cmtst.
>
> * config/aarch64/aarch64-simd-builtins.def (cmeq, cmge, cmgt, cmle,
> cmlt, cmgeu, c
On 19 August 2014 11:44, Alan Lawrence wrote:
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-builtins.c (aarch64_types_cmtst_qualifiers,
> TYPES_TST): Define.
> (aarch64_fold_builtin): Update pattern for cmtst.
>
> * config/aarch64/aarch64-protos.h
> (aarch64_const_
On 12 August 2014 15:55, Alan Lawrence wrote:
>> gcc/ChangeLog:
>>
>> * config/aarch64/aarch64.c (_one_cmpl3):
>> Reparameterize to...
>> (_one_cmpl3): with extra SIMD-register
>> variant.
>> (xor_one_cmpl3): New define_insn_and_split.
>>
>> * config/aarch6
On 12 August 2014 15:43, Alan Lawrence wrote:
> This patch adds SIMD register variants for and, ior, xor and not - similarly
> to add/sub, the H/W supports it, and it'll be more efficient if the values
> are there already, e.g. if passed as [u]int64x1_t parameters.
>
> gcc/ChangeLog:
>
> *
Sorry for wrong subject!
On 09/02/2014 07:03 PM, Marat Zakirov wrote:
Hi all!
Here's a simple optimization patch for Asan. It stores alignment
information into ASAN_CHECK which is then extracted by sanopt to
reduce number of "and 0x7" instructions for sufficiently aligned
accesses. I checked
On 18 August 2014 17:50, Alan Lawrence wrote:
> Well, you're right that it could be. So I presented the wrong justification.
>
> Clearly we would benefit from some better cost infrastructure here, ideally
> that is expressive, taken into account at all appropriate stages of the
> compiler, and tun
Hi again,
On 09/02/2014 04:28 PM, Jason Merrill wrote:
On 09/02/2014 10:17 AM, Paolo Carlini wrote:
Let's see if I can tease the case out...
I think you need to leave that hunk alone, and instead fix the new
testcase by treating = {} more like {}, just as we already don't
require a copy con
Hi all!
Here's a simple optimization patch for Asan. It stores alignment
information into ASAN_CHECK which is then extracted by sanopt to reduce
number of "and 0x7" instructions for sufficiently aligned accesses. I
checked it on linux kernel by comparing results of objdump -d -j .text
vmlinux
> Hmm, why not make -no-pg (does that exist?) and/or -mno-fentry
I'm not sure.
> do this? That is, I don't see the need for a new option.
That would be really odd behavior. An yes/no option whose default
is controlled by other object files' command line.
And -pg would be for all files in LTO, a
On Tue, 2014-09-02 at 00:03 -0700, Andi Kleen wrote:
> From: Andi Kleen
>
> I noticed that with the trunk compiler a range of the new rtl
> inlines show up as hot in a profiler during stage1. I think
> that happens because stage1 is not using optimization
> and does not inline plain "inline". An
On Wed, Aug 27, 2014 at 03:06:38PM -0400, Jason Merrill wrote:
> On 08/25/2014 07:43 AM, Marek Polacek wrote:
> > * semantics.c (finish_static_assert): Strip no-op conversions.
>
> I think I'd rather strip these in cxx_eval_builtin_function_call so that we
> don't have to deal with them in var
On 24 July 2014 11:18, Alan Lawrence wrote:
> The ACLE spec does not mention the int32x1_t, uint32x1_t, int16x1_t,
> uint16x1_t, int8x1_t or uint8x1_t types currently in arm_neon.h, but just
> 'standard' types int32_t, int16_t, etc. This patch is a global
> search-and-replace across arm_neon.h (an
Hi,
On 09/02/2014 04:28 PM, Jason Merrill wrote:
On 09/02/2014 10:17 AM, Paolo Carlini wrote:
Let's see if I can tease the case out...
I think you need to leave that hunk alone, and instead fix the new
testcase by treating = {} more like {}, just as we already don't
require a copy construct
On 08/29/2014 02:47 AM, Ilya Enkovich wrote:
> Seems your patch doesn't cover all cases. Attached is a modified
> patch (with your changes included) and a test where double constant is
> wrongly rematerialized. I also see in ira dump that there is still a
> copy of PIC reg created:
>
> Initializa
On 09/02/2014 10:17 AM, Paolo Carlini wrote:
Let's see if I can tease the case out...
I think you need to leave that hunk alone, and instead fix the new
testcase by treating = {} more like {}, just as we already don't require
a copy constructor call for copy-list-initialization.
Jason
On 09/01/2014 09:47 AM, Paolo Carlini wrote:
-constexpr A b = a; // { dg-error "mutable" }
+constexpr A b = a;
This is wrong; we still need to get an error here.
Jason
Hi,
On 09/02/2014 04:11 PM, Jason Merrill wrote:
On 09/01/2014 09:47 AM, Paolo Carlini wrote:
-constexpr A b = a;// { dg-error "mutable" }
+constexpr A b = a;
This is wrong; we still need to get an error here.
Hum, interesting. Neither current EDG nor current clang error out there.
L
OK.
Jason
The following patch adds more comparison patterns (with comments
on what is missing still).
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2014-09-02 Richard Biener
* fold-const.h (negate_expr_p): Declare.
* fold-const.c (negate_expr_p): Export.
The following patch removes dead code (blocks are never defered
because we iterate in a proper CFG order now) and avoids building
up the el_avail vector one element at a time.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2014-09-02 Richard Biener
* tree-ss
PR62294 reports that 4.9 does not emit an "incompatible pointer type"
warning in certain scenario. I unknowingly broke this in r207335, and
then fixed it in r210980, which is a follow-up to the former. But 4.9
doesn't have the latter. This patch is basically a backport of r210980,
only without t
On Tue, Sep 02, 2014 at 02:10:32PM +0200, Ulrich Weigand wrote:
> In any case, this test in can_combine_p rejects a combination for *two*
> different issues. One is the earlyclobber problem, which is what that
> 2004 thread was about, and which my patch back then relaxed for fixed
> hard register.
On Tue, Sep 2, 2014 at 2:36 PM, Ilya Tocar wrote:
> Hi,
>
> Along with intrinsics for adcx/adox (supported since 4.8) ICC also
> added intrinsics for adc/sbb [1]. This patch adds them.
> Bootstraps/passes make-check. Ok for trunk?
>
> [1]
> http://www.xlsoft.com/jp/products/intel/compilers/ccm/20
(Now for the real fix.)
This patch fixes the last two spots where -Wlogical-not-parentheses
warns. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62270#c3
if you want more info about the changes.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2014-09-02 Marek Polacek
PR fort
Ping on this series?
Thanks,
Kyrill
On 19/08/14 16:04, Kyrill Tkachov wrote:
Hi all,
This patch series converts the arm backend to output unified assembly
syntax for the VFP instructions.
This makes it more readable since most UAL mnemonics also include
various type suffixes such as .f32 and .
Hi,
Along with intrinsics for adcx/adox (supported since 4.8) ICC also
added intrinsics for adc/sbb [1]. This patch adds them.
Bootstraps/passes make-check. Ok for trunk?
[1]
http://www.xlsoft.com/jp/products/intel/compilers/ccm/2013/Release_Notes_u3.pdf
ChangeLog below:
gcc/
2014-09-02 Ilya
Appearantly we didn't exercise this before and thus it has gone
unnoticed that we don't properly special case single-RHSs on
GIMPLE.
Fixed as follows.
Bootstrapped on x86_64-unknown-linux-gnu, applied.
Richard.
2014-09-02 Richard Biener
* gimple-match-head.c (maybe_build_generic_op
Segher Boessenkool wreote:
> On Mon, Sep 01, 2014 at 10:39:10AM -0600, Jeff Law wrote:
> > On 09/01/14 05:38, Segher Boessenkool wrote:
> > >On Mon, Sep 01, 2014 at 11:36:07AM +0800, Bin.Cheng wrote:
> > >>>In the testcase (and comment in the proposed patch), why is combine
> > >>>combining four in
On Tue, Sep 02, 2014 at 10:36:27AM +0200, Richard Biener wrote:
> On Tue, Sep 2, 2014 at 3:56 AM, wrote:
> > From: Trevor Saunders
> >
> > Hi,
> >
> > There are still some issues to make this work really nicely, but this part
> > is
> > probably good enough its worth reviewing.
> >
> > For one
On Mon, Sep 01, 2014 at 09:28:09PM -0600, Jeff Law wrote:
> >Note that in this case we're talking about a hard register, not a pseudo.
> I was referring to r84 in Bin's message, not the condition code
> register. Unless I missed something it's set at the start of the
> sequence to the value 0, t
On Tue, Sep 02, 2014 at 10:02:38AM +0800, Bin.Cheng wrote:
> >> >Archaeology suggests this check is because the clobber might be an
> >> >earlyclobber. Which seems silly: how can it be a valid insn at all
> >> >in that case? It seems to me the check can just be removed. That
> >> >will hide your
May I use gomp_free_thread as a destructor for pthread_key_create?
Then I'll make initial_thread_tls_data global for the first case, but
how can I differentiate thread created by gomp_thread_start (second
case)?
2014-09-01 14:51 GMT+04:00 Jakub Jelinek :
> On Fri, Aug 29, 2014 at 10:40:57AM -0700,
Hi,
Similarly to ARM, where this issue was seen originally, and likely many
other targets, the Power ABI does not appear to have a relocation defined
to support taking a difference of two symbols in different sections each.
This is seen as a failure in gcc.c-torture/compile/pr60655-2.c:
Execu
In a native x86_64-linux toolchain in which
eh-table-registration is done explicitly (i.e. dl_iterate_phdr
and PT_GNU_EH_FRAME is *not* assumed, as that eliminates the
issue), the memory overhead for exception-initialization goes
beyond the 32768 bytes assumed in badalloc1.C and the test fails
for
On 30/08/14 20:03 +0200, François Dumont wrote:
Any news for my patch proposals ?
Regarding documentation of default minimum number of buckets, I don't
know where it has been documented but why do we need to document it
separately ? Could it be taken care by Doxygen ? Can't it get the
default
Hi,
while looking into c++/58102 and DR 1405 I noticed that we don't
implement DR 1453 either, sort of dual issue with volatile instead of
mutable. Tested x86_64-linux.
Thanks,
Paolo.
/cp
2014-09-02 Paolo Carlini
DR 1453
* class.c (check_field_dec
On Mon, 1 Sep 2014, Richard Biener wrote:
>
> The following patch tries to work towards fixing PR62291 by moving
> NEW_SETS/AVAIL_OUT adding strictly to insert_into_preds_of_block
> and the value / expression we wanted to insert. If doing that for
> other unrelated expressions this may cause fak
On Mon, Sep 1, 2014 at 10:25 PM, Andi Kleen wrote:
> From: Andi Kleen
>
> [This was an old patch of mine that has been posted before,
> but never made it in]
>
> This adds a new C/C++ option to force
> __attribute__((no_instrument_function)) on every function compiled.
>
> This is useful together
On 01/09/14 21:46 -0400, Ed Smith-Rowland wrote:
Index: include/bits/stl_function.h
===
--- include/bits/stl_function.h (revision 214680)
+++ include/bits/stl_function.h (working copy)
@@ -217,6 +217,10 @@
};
#if __cplusplus > 2
This completes conversion patterns (apart from commented case
which needs a new IL feature).
Bootstrapped on x86_64-unknown-linux-gnu, applied.
Richard.
2014-09-02 Richard Biener
* match-conversions.pd: Add more patterns.
Index: gcc/match-conversions.pd
Ping^2
Added Jason as maintainer for dwarf related things.
This hook will be used in the following patch:
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02172.html
Thanks,
Matthew
> Ping.
>
> Thanks,
> Matthew
>
> > Sent: 07 August 2014 07:21
> > > Please don't add target macros. Add a hook if
On Tue, Sep 2, 2014 at 10:36 AM, Steven Bosscher wrote:
> On Tue, Sep 2, 2014 at 9:22 AM, Andrew Pinski wrote:
>> On Tue, Sep 2, 2014 at 12:20 AM, Andi Kleen wrote:
>>>
there have been bugs in the past in the area of always_inline too.
>>>
>>> You're arguing for my patch. It would find those
On 09/01/2014 08:28 PM, Jakub Jelinek wrote:
This situation occurs when somebody decides to build GCC with
-fexeptions and -frtti which are forbidden for libsanitizer.
I don't see a reason for this, simply don't do that, libsanitizer AFAIK
isn't the only library where it is highly undesirable to
> On Sep 2, 2014, at 1:36 AM, Steven Bosscher wrote:
>
>> On Tue, Sep 2, 2014 at 9:22 AM, Andrew Pinski wrote:
>>> On Tue, Sep 2, 2014 at 12:20 AM, Andi Kleen wrote:
>>>
there have been bugs in the past in the area of always_inline too.
>>>
>>> You're arguing for my patch. It would find
On Tue, Sep 2, 2014 at 9:22 AM, Andrew Pinski wrote:
> On Tue, Sep 2, 2014 at 12:20 AM, Andi Kleen wrote:
>>
>>> there have been bugs in the past in the area of always_inline too.
>>
>> You're arguing for my patch. It would find those bugs.
>
>
> No I am arguing against it since the older versions
On Tue, Sep 2, 2014 at 3:56 AM, wrote:
> From: Trevor Saunders
>
> Hi,
>
> There are still some issues to make this work really nicely, but this part is
> probably good enough its worth reviewing.
>
> For one thing you can't use ggc hash_map or set in front ends with some types
> or gengtype wil
The auto_vec replacement missed one truncation.
Committed as obvious.
Richard.
2014-09-02 Richard Biener
PR tree-optimization/62695
* tree-ssa-structalias.c (find_func_clobbers): Add missing
vector truncate.
* gfortran.dg/pr62695.f90: New testcase.
Index: g
On Mon, Sep 1, 2014 at 6:33 PM, Andi Kleen wrote:
> From: Andi Kleen
>
> Only give a warning when gcc-ar/nm/ranlib cannot find the plugin.
> In this case do not pass a plugin argument to the wrapped program.
>
> This should make it work on non linker plugin systems, so
> that the build system can
1 - 100 of 104 matches
Mail list logo
