> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jeff Law
> Sent: Tuesday, December 10, 2013 6:31 AM
> To: Bin.Cheng
> Cc: gcc-patches List; Richard Biener; Zdenek Dvorak
> Subject: Re: [Ping]Two pending IVOPT patches
>
> O
On 12/09/13 16:18, Eric Botcazou wrote:
It's the pessimization introduced on the ARM (and other RISC targets) by the
distribution of truncations in simplify_truncation. Further information at:
http://gcc.gnu.org/ml/gcc/2013-12/msg00019.html
The change started as a simple address reassociatio
On 12/09/13 16:03, Marek Polacek wrote:
This patch fixes another instance of unchecked return value of
gimple_call_fn.
Only one thing is interesting: I found an ICE with -fvtable-verify=std
and -flto, that's why I don't run the test with LTO. This ICE is
unrelated to ubsan.
Regtested/bootstrap
Ping!
Original Message
Subject: [PATCH][RFA][PR middle-end/59285] Handle BARRIERS between
blocks in rtl_merge_blocks
Date: Thu, 05 Dec 2013 21:52:33 -0700
From: Jeff Law
To: gcc-patches
builtin-unreachable-6.c when compiled for armv7l has a conditional where
the fall-thr
Hi Yufeng,
Thanks for the quick response.
>> +#define ASM_MABI_SPEC"%{mabi=lp64*:}"
>
> Is '*' necessary here?
Removed it.
>> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
>> index b1b4eef..c1a9cbd 100644
>> --- a/gcc/config/aarch64/aarch64.c
>> +++ b/gcc/config/
On 2013/7/14 09:27 PM, Joseph S. Myers wrote:
> On Sun, 14 Jul 2013, Chung-Lin Tang wrote:
>
>> Original patch posted as part of Nios II patches:
>> http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01087.html
>>
>> This patch is to allow hexadecimal numbers to be used in option
>> arguments, e.g. -fal
On 12/09/13 16:17, Eric Botcazou wrote:
Ugh. I don't care that much :-) If you want to handle it, go ahead. I
would suggest a comment indicating why we've chosen to handle it.
OK, I can do that.
The only question left is would it be better to handle it in
extract_bit_field to catch other ca
Ping.
Thanks,
wei.
On Sat, Nov 23, 2013 at 10:46 AM, Wei Mi wrote:
> bootstrap and regression of the updated patch pass.
>
> On Sat, Nov 23, 2013 at 12:05 AM, Wei Mi wrote:
>> On Thu, Nov 21, 2013 at 12:19 AM, Zdenek Dvorak
>> wrote:
>>> Hi,
>>>
This patch works on the intrinsic calls han
On 12/09/13 19:46, bin.cheng wrote:
IVOPT adds original cand and tries to keep it the original IV is
because it does have an updating statement. For IVs picked up by
this patch, it doesn't have stepping statement, so no need/way to
leaving it untouched. It will be represented by candidates for
Ping x2.
On 2013/12/5 12:19 PM, Chung-Lin Tang wrote:
> Ping.
>
> On 2013/11/26 02:45 PM, Chung-Lin Tang wrote:
>> Hi Bernd,
>> I've updated the patch again, please see if it looks fit for approval
>> now. Including ChangeLog again for completeness.
>>
>> Thanks,
>> Chung-Lin
>>
>> 2013-11-26 Ch
> -Original Message-
> From: Bin.Cheng [mailto:amker.ch...@gmail.com]
> Sent: Monday, December 09, 2013 1:15 PM
> To: Jeff Law
> Cc: Bin Cheng; gcc-patches List
> Subject: Re: [PATCH PR41488]Recognize more induction variables by
> simplifying PEELED chrec in scalar evolution
>
> On Mon,
On Mon, Dec 9, 2013 at 12:12 PM, Yufeng Zhang wrote:
> On 12/03/13 21:24, Andrew Pinski wrote:
>>
>> Hi,
>>This is the final patch which adds support for the dynamic linker and
>> multi-lib directories for ILP32. I did not change multi-arch support as
>> I did not know what it should be chang
On Mon, Dec 9, 2013 at 2:57 PM, Joseph S. Myers wrote:
> On Mon, 9 Dec 2013, Yufeng Zhang wrote:
>
>> > -#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux-aarch64.so.1"
>> > +#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux%{mabi=ilp32:32}-aarch64.so.1"
>>
>> To be more explicit and consistent, the name of t
This patch fixes PR 55715, bogus cpplib diagnostics for subtraction
involving the most negative integer arising from the implementation of
subtraction as negation followed by falling through into the addition
case. The fix is simply to separate the subtraction implementation
from that of addition
> Ugh. I don't care that much :-) If you want to handle it, go ahead. I
> would suggest a comment indicating why we've chosen to handle it.
OK, I can do that.
> The only question left is would it be better to handle it in
> extract_bit_field to catch other cases, or is that too late?
I put it
It's the pessimization introduced on the ARM (and other RISC targets) by the
distribution of truncations in simplify_truncation. Further information at:
http://gcc.gnu.org/ml/gcc/2013-12/msg00019.html
The change started as a simple address reassociation trick for x32 and evolved
into a genera
Tobias Burnus wrote:
PS: I have now committed the attached patch as Rev. 205791.
Seemingly, I missed one test case. Committed the attached patch as
obvious, Rev. 205838.
Tobias
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuit
On Mon, 9 Dec 2013, Bernd Schmidt wrote:
> On 12/09/2013 11:42 PM, Joseph S. Myers wrote:
> > On Mon, 9 Dec 2013, Bernd Schmidt wrote:
> >
> >> Most of the compiler expects TYPE_ADDR_SPACE to be valid for things like
> >> initializing a MEM. The C frontend does not set it for arrays, which
> >> s
This patch fixes another instance of unchecked return value of
gimple_call_fn.
Only one thing is interesting: I found an ICE with -fvtable-verify=std
and -flto, that's why I don't run the test with LTO. This ICE is
unrelated to ubsan.
Regtested/bootstrapped on x86_64-linux, ok for trunk?
2013-
On Mon, 9 Dec 2013, Yufeng Zhang wrote:
> > -#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux-aarch64.so.1"
> > +#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux%{mabi=ilp32:32}-aarch64.so.1"
>
> To be more explicit and consistent, the name of the ILP32 loader shall have
> 'ilp32' instead of '32'. The ext
On 12/09/13 15:41, Eric Botcazou wrote:
But isn't the test bogus if it depends on the result of loading a zero
sized bitfield?
That's supported in Ada and the result is specified, it's the only allowed
value of the type of the bitfield (the type has precision 0 and is biased if
this value isn't
On Mon, 9 Dec 2013, Bernd Schmidt wrote:
> * Everything must live in an address space. There are several for
>global variables, constant data, and local variables. We have C
>frontend changes to apply and deal with implicit address spaces.
I think implicit address spaces should be dealt
On 12/09/2013 11:42 PM, Joseph S. Myers wrote:
> On Mon, 9 Dec 2013, Bernd Schmidt wrote:
>
>> Most of the compiler expects TYPE_ADDR_SPACE to be valid for things like
>> initializing a MEM. The C frontend does not set it for arrays, which
>> seems like an oversight caused by not setting other typ
> But isn't the test bogus if it depends on the result of loading a zero
> sized bitfield?
That's supported in Ada and the result is specified, it's the only allowed
value of the type of the bitfield (the type has precision 0 and is biased if
this value isn't zero). So this boils down to an imp
On Mon, 9 Dec 2013, Bernd Schmidt wrote:
> Most of the compiler expects TYPE_ADDR_SPACE to be valid for things like
> initializing a MEM. The C frontend does not set it for arrays, which
> seems like an oversight caused by not setting other type qualifiers for
> array types.
I see nothing in TR 1
OK for mainline, subject to testing there.
--
Joseph S. Myers
jos...@codesourcery.com
OK for mainline (subject to testing there, of course).
--
Joseph S. Myers
jos...@codesourcery.com
On 11/26/13 03:52, Bin.Cheng wrote:
On Tue, Nov 26, 2013 at 6:06 AM, Jeff Law wrote:
On 11/25/13 02:11, Bin.Cheng wrote:
Slightly tune to make iv cand choosing algorithm more accurate:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01574.html
It would help if you had some sample codes where
Back in April 2011, Richard S. submitted the implementation of
internal functions [1]. It originally had this hunk of code:
if (code == SSA_NAME
&& (g = SSA_NAME_DEF_STMT (ssa_name))
- && gimple_code (g) == GIMPLE_CALL)
+ && gimple_code (g) == GIMPL
On Fri, 2013-12-06 at 16:41 +0100, Richard Biener wrote:
> David Malcolm wrote:
> >I have a series of 13 follow-up patches which remove the remaining
> >"cfun"-using macros from basic-block.h
> >
> >Successfully bootstrapped®tested on x86_64-unknown-linux-gnu.
> >
> >These were pre-approved in sta
On 12/09/13 04:16, Eric Botcazou wrote:
Hi,
the new test gnat.dg/pack19.adb doesn't pass on some platforms because of the
target-dependent result of loads from bit-fields with size 0.
Unlike the stores to these bit-fields which are handled in an uniform way in
store_field:
/* If we have not
On Mon, Dec 9, 2013 at 5:48 AM, H.J. Lu wrote:
> On Mon, Dec 9, 2013 at 5:00 AM, H.J. Lu wrote:
>> On Mon, Dec 9, 2013 at 1:56 AM, Tejas Belagod wrote:
>>> Kirill Yukhin wrote:
Hello,
On 05 Dec 16:40, Kirill Yukhin wrote:
>
> On 05 Dec 05:30, H.J. Lu wrote:
>>
>>>
On 12/09/13 10:53, Eric Botcazou wrote:
Hi,
there is a small oddity in gen_int_libfunc since 2007:
if (GET_MODE_CLASS (mode) != MODE_INT
|| mode < word_mode || GET_MODE_BITSIZE (mode) > maxsize)
return;
I don't think that modes are meant to be compared like that, so the attac
Hi Kugan,
Thanks for the quick action.
On 12/09/13 11:20, Kugan wrote:
Thanks Yufeng for the review.
On 07/12/13 03:18, Yufeng Zhang wrote:
>> gcc trunk aarch64 bootstrapping fails with gas version 2.23.2 (with
>> error message similar to cannot compute suffix of object files) as this
>>
On Mon, 2013-12-09 at 16:47 -0500, David Malcolm wrote:
> Yes, longer-term I'd prefer member functions. The approach I posted
> approach gives identical results to the status quo after a trip through
> the preprocessor, so is somewhat lower-risk than introducing inlinable
> member functions. (and
On Fri, 2013-12-06 at 21:27 +0100, Richard Biener wrote:
> Oleg Endo wrote:
> >On Fri, 2013-12-06 at 16:57 +0100, Steven Bosscher wrote:
> >> On Fri, Dec 6, 2013 at 3:51 PM, David Malcolm wrote:
> >> > * asan.c (transform_statements): Eliminate use of
> >last_basic_block
> >> > in
On 12/09/13 11:04, Eric Botcazou wrote:
Hi,
the test doesn't pass on SPARC because of unaligned objects.
Tested on x86/Linux and SPARC/Solaris, OK for the mainline?
2013-12-09 Eric Botcazou
* gcc.dg/vect/pr58508.c: XFAIL for vect_no_align.
OK.
Jeff
On 12/09/13 11:05, Eric Botcazou wrote:
Hi,
the test requires vect_int, but it seems to me that it should require
vect_int_mult instead.
Tested on x86/Linux and SPARC/Solaris, OK for the mainline?
2013-12-09 Eric Botcazou
* gcc.dg/vect/vect-reduc-pattern-3.c: Require vect_int_mult
OK.
Jason
On 11/21/2013 12:41 PM, Jason Merrill wrote:
I had to change various things in cgraph/ipa in order to support the
notion of a comdat-local symbol which can only be referenced from within
that comdat, which is what I'm looking for feedback/approval for. The
change to can_refer_decl_in_current_uni
On 12/03/13 21:24, Andrew Pinski wrote:
Hi,
This is the final patch which adds support for the dynamic linker and
multi-lib directories for ILP32. I did not change multi-arch support as
I did not know what it should be changed to and internally here at Cavium,
we don't use multi-arch.
OK?
> "Dodji" == Dodji Seketeli writes:
Dodji> * include/line-map.h (linemap_get_file_highest_location): Declare
Dodji> new function.
Dodji> * line-map.c (linemap_get_file_highest_location): Define it.
I wasn't sure if this is the patch you were needing review for ...
Dodji> +bool linemap_ge
Hi,
I think the issue here is simply that the circumstances mentioned in the
existing comment can occur both for an NSDMI and for a default argument.
Tested x86_64-linux.
Thanks!
Paolo.
/
/cp
2013-12-09 Paolo Carlini
PR c++/59435
* parser.c (cp_par
On 11/21/2013 12:41 PM, Jason Merrill wrote:
I had to change various things in cgraph/ipa in order to support the
notion of a comdat-local symbol which can only be referenced from within
that comdat, which is what I'm looking for feedback/approval for. The
change to can_refer_decl_in_current_uni
On 12/05/2013 11:38 PM, Iyer, Balaji V wrote:
used the init_p value that comes out of stabilize_expr
I guess you didn't look at the patch I sent you...
Since you've fixed extract_free_variables, you don't need
call_to_lambda_fn_p at all, or to call stabilize_expr.
Why do you need to move a
This patch is the last performance patch that i have for wide-int.
This patch changes large multiply from taking precision/hbpwi *
precision/hbpwi multiplies to taking
#significant_bits1/hbpwi * #significant_bits2/hbpwi multiplications.
That was a significant number of multiplies on machines
Hi,
the test requires vect_int, but it seems to me that it should require
vect_int_mult instead.
Tested on x86/Linux and SPARC/Solaris, OK for the mainline?
2013-12-09 Eric Botcazou
* gcc.dg/vect/vect-reduc-pattern-3.c: Require vect_int_mult.
--
Eric BotcazouIndex: gcc.dg/vect/v
Hi,
the test doesn't pass on SPARC because of unaligned objects.
Tested on x86/Linux and SPARC/Solaris, OK for the mainline?
2013-12-09 Eric Botcazou
* gcc.dg/vect/pr58508.c: XFAIL for vect_no_align.
--
Eric BotcazouIndex: gcc.dg/vect/pr58508.c
===
Hi,
there is a small oddity in gen_int_libfunc since 2007:
if (GET_MODE_CLASS (mode) != MODE_INT
|| mode < word_mode || GET_MODE_BITSIZE (mode) > maxsize)
return;
I don't think that modes are meant to be compared like that, so the attached
patch replaces the direct comparison wit
Hello!
This is also how glibc generates exceptions.
libgcc/ChangeLog:
2013-12-09 Uros Bizjak
* config/i386/sfp-exceptions.c (__sfp_handle_exceptions): Emit SSE
instructions when __SSE_MATH__ is defined.
libatomic/ChangeLog:
2013-12-09 Uros Bizjak
* config/x86/fenv.c (__atom
On 12/09/2013 10:12 AM, Richard Sandiford wrote:
Richard Biener writes:
On Mon, Dec 9, 2013 at 3:49 PM, Kenneth Zadeck wrote:
On 12/08/2013 05:35 AM, Richard Biener wrote:
Richard Sandiford wrote:
Kenneth Zadeck writes:
#define WIDE_INT_MAX_ELTS \
- ((4 * MAX_BITSIZE_MODE_ANY_INT +
On Thu, Nov 21, 2013 at 9:57 PM, Alan Modra wrote:
> David,
> Here comes the inevitable followup.. I broke backwards compatibility
> when adding an extra field to ffi_cif. I'd like to import again from
> upstream, where I've already fixed the problem.
>
> https://sourceware.org/ml/libffi-discuss
Hi Aldy,
Answers to your questions are given below. Here are the fixed ChangeLog
entries. Is it OK now?
Thanks,
Balaji V. Iyer.
Gcc/ChangeLog
2013-12-09 Balaji V. Iyer
* omp-low.c (expand_simd_clones): Added a new parameter called "type."
(ipa_omp_simd_clone): Added
On Mon, Dec 09, 2013 at 04:06:35PM +0100, Bernd Schmidt wrote:
> Everything after register allocation is currently in pass_postreload
> rather than pass_rest_of_compilation. This seems arbitrary to me, and
> for a target that doesn't do register allocation, pass_postreload isn't
> run, so the very
Hi,
as described in the trail, my implementation of lwg/596 isn't complete
and finally somebody noticed ;) But isn't much work. Richard, if you
distilled the testcase from a larger piece of code, you may want to
double check it on that too (in case of remaining issues, please let me
know asap
nvptx doesn't use register allocation and avoids all the postreload
passes. It needs to call thread_prologue_and_epilogue_insns manually
from reorg.
gcc/
* function.c (thread_prologue_and_epilogue_insns): No longer static.
* function.h (thread_prologue_and_epilogue_insns): Declare.
-
ptx assembly has some unusual requirements, Symbols must be declared
before use, and only functions (but not variables) can have forward
declarations.
This patch deals with getting variable definitions in the right order,
emitting declarations for undefined symbols, and emitting declarations
for
On ptx we need to decorate call insns with the arguments that are
being passed. This is kind of hard to do with the existing
infrastructure, so this patch adds two more hooks, one called just
before argument registers are loaded (once for each arg), and the
other just after the call is complete.
On ptx, we'll be using pseudos to pass function args as well, and
there's one assert that needs to be toned town to make that work.
gcc/
* expr.c (use_reg_mode): Just return for pseudo registers.
Index: gcc/expr.c
===
This adds two hooks to determine address spaces for local and global
variables, and changes various places in the compiler to ensure stuff
goes to the right place.
If a type is given an address space in this way, the
TYPE_QUAL_AS_IMPLICIT is set. Such a flag is needed to properly handle
such type
The nvptx backend is slightly unusual in that call insns set a pseudo.
The combiner is surprised by this and allows combining them into other
insns, which remain as INSN rather than CALL_INSN. Aborts ensue.
gcc/
* combine.c (try_combine): Don't allow a call as one of the source
insns.
---
Richard Biener writes:
> On Mon, Dec 9, 2013 at 3:49 PM, Kenneth Zadeck
> wrote:
>> On 12/08/2013 05:35 AM, Richard Biener wrote:
>>>
>>> Richard Sandiford wrote:
Kenneth Zadeck writes:
>
> #define WIDE_INT_MAX_ELTS \
> - ((4 * MAX_BITSIZE_MODE_ANY_INT +
Another small patchlet to prepare for implicit address spaces. We'll
modify char_array_type_node etc. to have an address space for nvptx, and
we'll need to be careful to retain it in fix_string_type.
gcc/c-family/
* c-common.c (fix_string_type): Get the element type from the value's
type if po
Consider
int x; /* Global address space is implicit for nvptx. */
int *p = &x;
where x is a variable in __global address space, and p is a generic
pointer. We won't get very far if this doesn't work, so we must change
the C frontend to allow this conversion. This works together with the
AS_CONVE
We have committed several backports from trunk to linaro/gcc-4_8-branch:
r200956 as r203832 ([AArch64] -mcmodel=tiny -fPIC GOT support)
r204336 as r204569 (Fix testsuite testcase
neon-vcond-[ltgt,unordered].c)
r203267, r203603 and r204247 as r204570 (Fix PR target/58423)
r197526: rever
ptx assembly follows rather different rules than what's typical elsewhere.
We need a new hook to add a " };" string when we are finished outputting a
variable.
gcc/
* target.def (decl_end): New hook.
* varasm.c (assemble_variable_contents, assemble_constant_contents):
Use it.
* doc/tm.texi.i
On 12/09/2013 10:01 AM, Richard Biener wrote:
On Mon, Dec 9, 2013 at 3:49 PM, Kenneth Zadeck wrote:
On 12/08/2013 05:35 AM, Richard Biener wrote:
Richard Sandiford wrote:
Kenneth Zadeck writes:
#define WIDE_INT_MAX_ELTS \
- ((4 * MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1)
To be used together with the no_register_allocation hook.
Everything after register allocation is currently in pass_postreload
rather than pass_rest_of_compilation. This seems arbitrary to me, and
for a target that doesn't do register allocation, pass_postreload isn't
run, so the very last few pass
There are two ways symbols can be output in ptx, either as plain "x",
which represents the address in the .global address space, or as
"generic(x)" which is the converted form to a generic address. To
distinguish the cases, it's necessary to allow ADDR_SPACE_CONVERT_EXPRs
in initializers, and to d
On 12/09/2013 02:31 PM, Richard Biener wrote:
> On Mon, Dec 9, 2013 at 3:08 PM, Andreas Schwab wrote:
>> The rules to install the dummy libgcc_bc library have never worked as
>> intented, probably due to the fact that the fedora gcc package installs
>> it by hand, ignoring all damage that has been
The last user of this was in objc and has been removed a while ago.
gcc/c-family/
* c-common.h (enum c_tree_index): Remove CTI_INT_ARRAY_TYPE.
(int_array_type_node): Remove.
* c-common.c (c_common_nodes_and_builtins): Don't build it.
--
There's code in function.c to set the return register to the address of
a returned structure even though the return really happens through the
struct pointer passed as an invisible argument. This is unwanted on ptx,
where having a return value does not match the declaration of the
function or the
Most of the compiler expects TYPE_ADDR_SPACE to be valid for things like
initializing a MEM. The C frontend does not set it for arrays, which
seems like an oversight caused by not setting other type qualifiers for
array types.
gcc/
* tree.h (set_type_quals): Declare.
* tree.c (set_type_quals):
This goes together with patch #13.
This adds a target hook to avoid doing register allocation or reload and
changes some code not to crash in such a case.
gcc/
* target.def (no_register_allocation): New data hook.
* doc/tm.texi.in: Add @hook TARGET_NO_REGISTER_ALLOCATION.
* doc/tm.texi: Regene
On Mon, Dec 9, 2013 at 3:49 PM, Kenneth Zadeck wrote:
> On 12/08/2013 05:35 AM, Richard Biener wrote:
>>
>> Richard Sandiford wrote:
>>>
>>> Kenneth Zadeck writes:
#define WIDE_INT_MAX_ELTS \
- ((4 * MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1) \
>>>
This fixes an oversight where a C_MAYBE_CONSTANT_EXPR could survive
until gimplification and trigger an assert.
gcc/c-family/
* c-common.c (c_fully_fold_internal): Handle ADDR_SPACE_CONVERT_EXPR.
Index: gcc/c-family/c-com
Use fix_string_type to get all string types.
When making a decl for __FUNCTION__ we use a slightly different method
than elsewhere to arrive at a string type. This changes it to use the
common idiom. On ptx these types will have an address space, and this
ensures that we don't drop it when consti
This patch fixes a bug on ARM where we can end up generating invalid
addresses for the LDRD/STRD peepholes. We then end up with an ICE later
on when we check the results. The patch does more strict validation of
the addresses, including having better tests for side effects that we
can't handle.
It turns out that we're calling eliminate_regs for global variables which
can't possibly have eliminable regs in their decl. At that point,
reg_eliminate can be NULL. This patch avoids unnecessary work, and
allows us to add an assert to eliminate_regs later.
gcc/
* dbxout.c (dbxout_symbol): Don
This is actually an old patch from the C6X 40-bit-int patchkit which
fell through the cracks. It turns out to be necessary for ptx to get
correct behaviour for BImode.
gcc/
* stor-layout.c (get_mode_bounds): Use GET_MODE_PRECISION, not
GET_MODE_BITSIZE. Handle BImode specially.
-
ptx doesn't have indirect jumps, so CODE_FOR_indirect_jump may not be
defined. Add a sorry.
gcc/
* optabs.c (emit_indirect_jump): Test HAVE_indirect_jump and emit a
sorry if necessary.
Index: gcc/optabs.c
==
There is a bug in the overflow check. The overflow check tries to assume that
signed integers will wrap around on overflow, and thus a number that wraps
around after a multiplication by 10 should no longer be divisible by 10.
Unfortunately, signed integer overflow is undefined behavior (see sect
We'll be the first port to use BImode and have STORE_FLAG_VALUE==-1.
That has exposed some bugs, one of them is in combine where we can end
up calling num_sign_bit_copies for a BImode value. However, the return
value is always 1 in that case, so it doesn't tell us anything and is
going to be misin
There's some code in get_uncond_jump_length to emit and then delete a
label and a jump. If a target doesn't use register allocation, this
fails a "reload_completed || bb != NULL" assert in df_insn_delete.
Fixed by instead emitting the two insns into a sequence which we then
just discard.
gcc/
I'll be submitting our current ptx backend in a series of 23 patches in
reply to this mail. This is currently a work-in-progress and still rough
around the edges. We'd like to do all our OpenACC work on the gomp4
branch, so I'm submitting this as a proposal to see if it would be
acceptable for this
On 12/08/2013 05:35 AM, Richard Biener wrote:
Richard Sandiford wrote:
Kenneth Zadeck writes:
#define WIDE_INT_MAX_ELTS \
- ((4 * MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1) \
- / HOST_BITS_PER_WIDE_INT)
+ (((MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1)\
+
This is a first patch speeding up PTA for PR38474 (this patch not
so much for this particular testcase, but it should in general).
The reduced testcase now compiles in 197s for me (down from 207s).
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2013-12-09 Richard Bien
On Mon, Dec 09, 2013 at 03:29:38PM +0100, Jakub Jelinek wrote:
> On Mon, Dec 09, 2013 at 03:23:30PM +0100, Marek Polacek wrote:
> > We ICEd on the following testcase with -fsanitize=null and vtable
> > verification on, because gimple_call_fn returns NULL for UBSAN_*
> > internal functions. Fixed b
On Mon, Dec 09, 2013 at 03:28:21PM +0100, Martin Jambor wrote:
> 2013-12-09 Martin Jambor
>
> * gcc.c-torture/compile/pr39834.c: Remove optimization level option.
> * gcc.c-torture/compile/pr48929.c: Likewise.
> * gcc.c-torture/compile/pr55569.c: Likewise.
> * gcc.c-tort
On Mon, Dec 9, 2013 at 3:08 PM, Andreas Schwab wrote:
> The rules to install the dummy libgcc_bc library have never worked as
> intented, probably due to the fact that the fedora gcc package installs
> it by hand, ignoring all damage that has been done. The target that
> creates libgcj_bc.la for
On Mon, Dec 09, 2013 at 03:23:30PM +0100, Marek Polacek wrote:
> We ICEd on the following testcase with -fsanitize=null and vtable
> verification on, because gimple_call_fn returns NULL for UBSAN_*
> internal functions. Fixed by checking the result for NULL before
> accessing its TREE_CODE.
>
> R
Hi,
I've noticed that test testsuite/gcc.c-torture/compile/sra-1.c that I
added yeas ago is run multiple times at -O1 because that level is
specified in the test. I looked for others such tests in that
directory and found a few more, all added by Honza :-) So this patch:
- removes the -O level s
We ICEd on the following testcase with -fsanitize=null and vtable
verification on, because gimple_call_fn returns NULL for UBSAN_*
internal functions. Fixed by checking the result for NULL before
accessing its TREE_CODE.
Regtested/bootstrapped on x86_64-linux, ok for trunk?
2013-12-09 Marek Pol
The rules to install the dummy libgcc_bc library have never worked as
intented, probably due to the fact that the fedora gcc package installs
it by hand, ignoring all damage that has been done. The target that
creates libgcj_bc.la for the testsuite is mucking around with internal
details that will
Maxim Kuvyrkov writes:
> My recent patches to cleanup support for Android/Bionic for *-linux-*
> targets broke mips64-linux and s390x-linux builds. Unfortunately, these
> targets fell out from the test coverage of these cleanups.
>
> The problems are in missing declarations, and are trivial to fi
On Mon, Dec 9, 2013 at 5:00 AM, H.J. Lu wrote:
> On Mon, Dec 9, 2013 at 1:56 AM, Tejas Belagod wrote:
>> Kirill Yukhin wrote:
>>>
>>> Hello,
>>>
>>> On 05 Dec 16:40, Kirill Yukhin wrote:
On 05 Dec 05:30, H.J. Lu wrote:
>
> Kirill, can you take a look why it doesn't work for x86?
On Mon, Dec 9, 2013 at 1:39 PM, Bernd Edlinger
wrote:
> On Fri, 6 Dec 2013 11:51:15, Richard Biener wrote:
>>
>> On Fri, Dec 6, 2013 at 11:15 AM, Bernd Edlinger
>> wrote:
>>> Hi,
>>>
>>> On Thu, 5 Dec 2013 15:10:51, Richard Biener wrote:
On Thu, Dec 5, 2013 at 1:27 PM, Bernd Edlinger
>>
On Mon, Dec 9, 2013 at 1:56 AM, Tejas Belagod wrote:
> Kirill Yukhin wrote:
>>
>> Hello,
>>
>> On 05 Dec 16:40, Kirill Yukhin wrote:
>>>
>>> On 05 Dec 05:30, H.J. Lu wrote:
Kirill, can you take a look why it doesn't work for x86?
>>>
>>> Okay, I'll look at this.
>>
>>
>> I've looked at t
On Mon, Dec 2, 2013 at 4:49 AM, H.J. Lu wrote:
> Hi,
>
> "ld" is a special name for GCC driver. find_a_file has
>
> #ifdef DEFAULT_LINKER
> if (! strcmp (name, "ld") && access (DEFAULT_LINKER, mode) == 0)
> return xstrdup (DEFAULT_LINKER);
> #endif
> #endif
>
> It does 2 things:
>
>
On Fri, 6 Dec 2013 11:51:15, Richard Biener wrote:
>
> On Fri, Dec 6, 2013 at 11:15 AM, Bernd Edlinger
> wrote:
>> Hi,
>>
>> On Thu, 5 Dec 2013 15:10:51, Richard Biener wrote:
>>>
>>> On Thu, Dec 5, 2013 at 1:27 PM, Bernd Edlinger
>>> wrote:
Hi Richard,
I had just an idea how to so
1 - 100 of 124 matches
Mail list logo
