> On 12/07/13 03:44, Eric Botcazou wrote:
>>> I'd certainly be concerned. Ports have (for better or worse) keyed on
>>> BLKmode rather than looking at the underlying types. So if something
>>> which was previously SImode or DImode is now BLKmode, there's a nonzero
>>> chance we're going to change h
Am 12/06/2013 10:32 AM, schrieb Richard Biener:
On Thu, Dec 5, 2013 at 4:38 PM, Georg-Johann Lay wrote:
Am 12/05/2013 04:09 PM, schrieb Richard Biener:
On Thu, Dec 5, 2013 at 3:53 PM, Georg-Johann Lay wrote:
This is a fix of a wrong warning for a bas ISR name. The assumption was
that if DEC
On Sat, Dec 7, 2013 at 11:28 AM, Richard Sandiford
wrote:
> Kenneth Zadeck writes:
>>> +/* One could argue that GET_MODE_PRECISION (TYPE_MODE (type))
>>> + should always be the same as TYPE_PRECISION (type).
>>> + However, it is not. Since we are converting from tree to
>>> +
Hi,
this is fixed in mainline. Tested x86_64-linux.
Thanks,
Paolo.
///
2013-12-09 Paolo Carlini
PR c++/52707
* g++.dg/cpp0x/deleted2.C: New.
Index: g++.dg/cpp0x/deleted2.C
===
--- g++.dg/cpp0
On Mon, Dec 9, 2013 at 6:15 AM, Bin.Cheng wrote:
> On Mon, Dec 9, 2013 at 12:00 PM, Jeff Law wrote:
>> On 12/06/13 19:44, Bin.Cheng wrote:
Right. Based on reading the archives, it looks like this stuff is/was
generated by PRE. I also suspect jump threading can create them. There
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 this. It seems that `CANNOT_CHANGE_MODE_CLASS'
is too conservative for x86.
In rtlanal.c we hav
On Mon, Dec 9, 2013 at 10:07 AM, Bernd Edlinger
wrote:
>> On 12/07/13 03:44, Eric Botcazou wrote:
I'd certainly be concerned. Ports have (for better or worse) keyed on
BLKmode rather than looking at the underlying types. So if something
which was previously SImode or DImode is now B
On 06/12/13 00:54, Tom de Vries wrote:
> On 30-03-13 18:11, Tom de Vries wrote:
>> Richard,
>>
>> This patch series adds analysis of register usage of functions for usage by
>> IRA.
>> The original post is here
>> ( http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01234.html ).
>>
>> This patch implem
Hmm, it looks like this has not been approved/applied, but I also
have not seen any NACK.
This does address an annoying (and hard for novices to understand)
roadblock for someone installing GCC manually. Can this go in?
Gerald
On Sat, 24 Aug 2013, FX wrote:
> ping
>
>
>> Given that I did not
Il 09/12/2013 11:46, Gerald Pfeifer ha scritto:
> Hmm, it looks like this has not been approved/applied, but I also
> have not seen any NACK.
>
> This does address an annoying (and hard for novices to understand)
> roadblock for someone installing GCC manually. Can this go in?
I'm not sure why t
It looks like this has not been applied, FX?
Were you waiting for further approval? If so: okay with the change
proposed by Andrew.
Thanks,
Gerald
On Mon, 29 Jul 2013, Andrew Haley wrote:
> On 07/29/2013 02:06 PM, FX wrote:
>> +build of a native compiler on @samp{x86_64-unknown-linux-gnu}, bewa
Richard Biener writes:
> On Sat, Dec 7, 2013 at 11:28 AM, Richard Sandiford
> wrote:
>> Kenneth Zadeck writes:
+/* One could argue that GET_MODE_PRECISION (TYPE_MODE (type))
+ should always be the same as TYPE_PRECISION (type).
+ However, it is not. Since we are c
> I'm not sure why this should be different for x86_64 compared to all
> other bi-arch toolchains?
It’s not, but it’s a particularly common one and has been reported multiple
times here and on gcc-help. If we can help these users early, we spare
ourselves the time to reply to such reports. (Also
On Mon, 9 Dec 2013, FX wrote:
> Look at this as a diagnostics bug: our current diagnostics for this
> pretty common situation sucks. It comes late in the compilation, and
> the message itself isn’t helpful.
Totally seconded.
Paolo, I have been running into this myself and was confused at
first.
> Were you waiting for further approval? If so: okay with the change
> proposed by Andrew.
Thanks, committed as rev. 205802 with Andrew’s change.
FX
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 nothing to store, do nothing unless the expr
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
>> particular version does not support -mabi=lp64. It succeeds with later
>> versi
ping
Hi all,
This patch adds initial support for the Cortex-A12 core. It is architecturally
identical to the Cortex-A7 and Cortex-A15 cores. This adds the -mcpu=cortex-a12
option and an rtx costs table and wires it up in the .md files etc. The option
is added to the documentation.
Tested arm-none
On 09/12/13 11:43, Kyrill Tkachov wrote:
> Hi all,
>
> This patch adds initial support for the Cortex-A12 core. It is
> architecturally
> identical to the Cortex-A7 and Cortex-A15 cores. This adds the
> -mcpu=cortex-a12
> option and an rtx costs table and wires it up in the .md files etc. The
Since there is already the __divtf3@GCC_3.0 compatibility alias in
libgcc we need to attach an explicit symbol version to the real __divtf3
in order to get it exported. This fixes the unversioned reference in
libgfortran.so, and fixes the failure of gfortran.dg/erf_3.F90. Tested
on ia64-suse-linu
Tejas Belagod writes:
> 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 this. It seems that `CANNOT_CHANGE_MODE_CLASS'
>>
On Mon, Dec 09, 2013 at 11:43:24AM +, Kyrill Tkachov wrote:
> 2013-12-09 Kyrylo Tkachov
>
> * config/arm/arm.md (generic_sched): Add cortexa12.
> (generic_vfp): Likewise.
> * config/arm/arm.c (cortexa12_extra_costs): New cost table.
> (arm_cortex_a12_tune): New tuning st
On 9/12/2013, at 8:21 am, Maxim Kuvyrkov wrote:
> On 9/12/2013, at 3:24 am, Jan-Benedict Glaw wrote:
>
>> Hi Maxim!
>>
>> One of your recent libc<->android clean-up patches broke the
>> mips64-linux target as a side-effect, see eg.
>> http://toolchain.lug-owl.de/buildbot/show_build_details.php
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
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 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 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 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?
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
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
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
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
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
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: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
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 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)\
+
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
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/
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 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
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
==
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.
-
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 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.
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 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
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 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
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):
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
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.
--
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
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
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
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)
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
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
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
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
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 +
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.
---
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
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
===
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.
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
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.
-
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
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 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 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
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 +
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
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
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
===
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
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
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
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
> "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
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?
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
OK.
Jason
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
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 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 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
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 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
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 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 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
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 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
OK for mainline (subject to testing there, of course).
--
Joseph S. Myers
jos...@codesourcery.com
OK for mainline, subject to testing there.
--
Joseph S. Myers
jos...@codesourcery.com
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
1 - 100 of 124 matches
Mail list logo
