On Tue, Dec 3, 2013 at 2:05 AM, H.J. Lu wrote:
> emit_memset fails to adjust destination address after gen_strset, which
> leads to the wrong address in aliasing info. This patch fixes it.
> Tested on Linux/x86-64. OK to install?
>
> 2013-12-03 H.J. Lu
>
> PR target/59363
>
On Mon, 2 Dec 2013, Kenneth Zadeck wrote:
> On 12/02/2013 03:34 PM, Richard Sandiford wrote:
> > Kenneth Zadeck writes:
> > > see wide-int.h around line 290
> > >
> > > the MAX_BITSIZE_MODE_ANY_INT is the largest mode on the machine. however
> > > if the value coming in is an unsigned number of
Hi Uros, HJ,
I checked expand_movmem_epilogue - it seemingly doesn't have such a
problem, so the patch is ok.
We might want to add similar adjust_automodify_address_nv call to here as well:
if (TARGET_64BIT)
{
dest = change_address (destmem, DImode, destptr);
emit_
Hi, I'm getting a bootstrap fail with Go with our custom patched
compiler (it adds that warning):
09:48 < richi> ../../../libgo/runtime/go-signal.c: In function
'runtime_sighandler':
09:48 < richi> ../../../libgo/runtime/go-signal.c:221:4: error: call to
function 'ru
On Tue, 3 Dec 2013, Jakub Jelinek wrote:
> Hi!
>
> tree-nested.c uses declare_vars with last argument true, which
> relies on BLOCK_VARS of gimple_bind_block being a tail
> of the gimple_bind_vars chain. But unfortunately a debug info
> improvement I've added to gimplify_var_or_parm_decl 4 years
On Mon, 2 Dec 2013, Jeff Law wrote:
> On 12/02/13 15:51, Jakub Jelinek wrote:
> > Hi!
> >
> > On Sat, Nov 30, 2013 at 12:38:30PM +0100, Eric Botcazou wrote:
> > > > Rather than adding do_pending_stack_adjust () in all the places,
> > > > especially
> > > > when it isn't clear whether emit_conditi
On Tue, 3 Dec 2013, Richard Biener wrote:
>
> Hi, I'm getting a bootstrap fail with Go with our custom patched
> compiler (it adds that warning):
>
> 09:48 < richi> ../../../libgo/runtime/go-signal.c: In function
>'runtime_sighandler':
> 09:48 < richi> ../../../libgo/runtime/go-s
Jeff Law writes:
> On 12/01/13 23:12, Yury Gribov wrote:
>> > This is causing all the tests being run on all targets,
>> > even if libsanitizer is not supported,
>> > most of them failing due to link errors.
>>
>> Thanks for the info and sorry about this. I should probably check
>> non-sanitiz
On Mon, 2 Dec 2013 15:42:48, Richard Biener wrote:
>
> On Wed, Nov 20, 2013 at 11:48 AM, Bernd Edlinger
> wrote:
>> Hello Richard,
>>
>> as a follow-up patch to the bit-fields patch(es), I wanted to remove the
>> dependencies on
>> the variable flag_strict_volatile_bitfields from expand_assignmen
On 12/02/2013 10:15 PM, Tim Shen wrote:
...for optimization purpose. Should be done in one month.
Great. Consider that we are now in Stage 3, until mid of February.
Considering that is a new feature, I think we have some leeway
in terms of timing, but definitely we can't commit invasive change
.. I meant mid of *January* of course.
Paolo.
On Tue, Dec 3, 2013 at 10:47 AM, Bernd Edlinger
wrote:
> On Mon, 2 Dec 2013 15:42:48, Richard Biener wrote:
>>
>> On Wed, Nov 20, 2013 at 11:48 AM, Bernd Edlinger
>> wrote:
>>> Hello Richard,
>>>
>>> as a follow-up patch to the bit-fields patch(es), I wanted to remove the
>>> dependencies on
>>>
On Tue, Dec 3, 2013 at 10:59 AM, Richard Biener
wrote:
> On Tue, Dec 3, 2013 at 10:47 AM, Bernd Edlinger
> wrote:
>> On Mon, 2 Dec 2013 15:42:48, Richard Biener wrote:
>>>
>>> On Wed, Nov 20, 2013 at 11:48 AM, Bernd Edlinger
>>> wrote:
Hello Richard,
as a follow-up patch to the bi
On Tue, Dec 3, 2013 at 4:47 AM, Paolo Carlini wrote:
> Great. Consider that we are now in Stage 3, until mid of February.
> Considering that is a new feature, I think we have some leeway in
> terms of timing, but definitely we can't commit invasive changes not fixing
> regressions while in Stage
> The situation hasn't changed in the last four days.
Thanks. Do you think you can check the patch in question?
-Y
On Tue, 3 Dec 2013 10:59:15, Richard Biener wrote:
>
> On Tue, Dec 3, 2013 at 10:47 AM, Bernd Edlinger
> wrote:
>> On Mon, 2 Dec 2013 15:42:48, Richard Biener wrote:
>>>
>>> On Wed, Nov 20, 2013 at 11:48 AM, Bernd Edlinger
>>> wrote:
Hello Richard,
as a follow-up patch to the bit-f
On Mon, Dec 2, 2013 at 6:38 PM, Xinliang David Li wrote:
> Points to solver has a bug that can cause complex constraints to be
> skipped leading to wrong points-to results. In the case that exposed
> the problem, there is sd constraint: x = *y which is never processed.
> 'y''s final points to set
> The trigger is a latent problem in the ada gcc_interface.
>
> That is we have a bit-field of exactly 8 bit size, which is not
> byte-aligned, but DECL_MODE=QImode, DECL_BIT_FIELD=false which looks quite
> strange, and is totally different from how C structures look like. I should
> mention that
Hi,
thus, as agreed a few days ago, I audited duplicate_decls for those
pairs of error and permerror where we want to use inform. I found at
least a straightforward case having to do with pragma omp, but other
cases required a little more work (I suspected that). For example in
some cases we
Hi,
This is my proposal for ulimately getting rid of the nasty
store_fixed_bit_field recursion.
IMHO, the root of the recursion trouble is here:
@@ -1007,12 +1013,8 @@ store_fixed_bit_field (rtx op0, unsigned
if (MEM_P (op0))
{
mode = GET_MODE (op0);
if (GET_MODE_BITSIZE (m
> Yes. I somehow did expect DECL_BIT_FIELD to be something simple,
> without dependency on if -fstrict-volatile-bitfields is given, or what
> Language front-end generated it, or if STRICT_ALIGNMENT is defined.
Yes, it should be that way, and everything else is a bug.
--
Eric Botcazou
On Mon, Dec 02, 2013 at 11:04:39PM -0700, Jeff Law wrote:
> On 11/28/13 16:50, Alan Modra wrote:
> >
> >This is due to that innocuous seeming change of setting
> >lra_in_progress before calling check_rtl(), in combination with
> >previous changes Vlad made to the rs6000 backend here:
> >http://gcc.
On Tue, Dec 3, 2013 at 12:01 PM, Bernd Edlinger
wrote:
> Hi,
>
> This is my proposal for ulimately getting rid of the nasty
> store_fixed_bit_field recursion.
>
> IMHO, the root of the recursion trouble is here:
>
> @@ -1007,12 +1013,8 @@ store_fixed_bit_field (rtx op0, unsigned
>
>if (MEM_P
>
>> Yes. I somehow did expect DECL_BIT_FIELD to be something simple,
>> without dependency on if -fstrict-volatile-bitfields is given, or what
>> Language front-end generated it, or if STRICT_ALIGNMENT is defined.
>
> Yes, it should be that way, and everything else is a bug.
>
I tried something l
On Mon, Dec 02, 2013 at 05:43:17PM +0100, Konstantin Serebryany wrote:
> > No, so your patch doesn't regress anything. I can configure with
> > --disable-libsanitizer to skip build of libsanitizer, although it
> > would be nice to support RHEL5 derived long-term distributions.
> Ok, so this does no
On 2 December 2013 23:44, Vladimir Makarov wrote:
> If somebody with the rights approves, I can commit it tomorrow.
>
> 2013-12-02 Vladimir Makarov
>
> * config/aarch64/aarch64.c (aarch64_frame_pointer_required): Check
> LR_REGNUM.
> (aarch64_can_eliminate): Don't check
> I tried something like this, and it did boot-strap, but failed in some acats
> tests:
Am I supposed to guess which ones? Note that you can have non-byte-aligned
aggregate fields in Ada, i.e. arrays, so ARRAY_REFs can presumably reach here.
--
Eric Botcazou
> From: ebotca...@adacore.com
> To: bernd.edlin...@hotmail.de
> CC: gcc-patches@gcc.gnu.org; richard.guent...@gmail.com
> Subject: Re: [PATCH] Strict volatile bit-fields clean-up
> Date: Tue, 3 Dec 2013 13:00:25 +0100
>
>> I tried something like this, and it
On Tue, Dec 3, 2013 at 12:45 AM, Michael Zolotukhin
wrote:
> Hi Uros, HJ,
>
> I checked expand_movmem_epilogue - it seemingly doesn't have such a
> problem, so the patch is ok.
>
> We might want to add similar adjust_automodify_address_nv call to here as
> well:
> if (TARGET_64BIT)
>
> Here is the updated patch. Tested on Linux/x86-64. It
> fixed git. OK to install?
>
> Thanks.
>
> --
> H.J.
> ---
> gcc/
>
> 2013-12-03 H.J. Lu
>
> PR target/59363
> * config/i386/i386.c (emit_memset): Adjust destination address
> after gen_strset.
> (expand_setmem_epi
Hi Jeff,
please find attached the patch (incl. test cases) for the unaligned read BUG
that I found while investigating
on PR#57748: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
one test case is this one:
pr57748-3.c:
/* PR middle-end/57748 */
/* { dg-do run } */
/* wrong code in expand_exp
On Thu, Nov 28, 2013 at 12:23:43AM +0100, Tom de Vries wrote:
> Committed to trunk.
>
> Also ok for 4.8 branch? It's a 4.8/4.9 regression.
Ok, but I guess you need to adjust your patch for 4.8 (tree_to_*
and tree_fits_* to host_integerp/tree_low_cst), so please make sure
you test it before commit
On 12/03/13 06:48, Jeff Law wrote:
On 12/02/13 08:47, Yufeng Zhang wrote:
Ping~
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03360.html
Thanks,
Yufeng
On 11/26/13 15:02, Yufeng Zhang wrote:
On 11/26/13 12:45, Richard Biener wrote:
On Thu, Nov 14, 2013 at 12:25 AM, Yufeng
Zhangwrote:
On Tue, Dec 3, 2013 at 4:41 AM, Jan Hubicka wrote:
>> Here is the updated patch. Tested on Linux/x86-64. It
>> fixed git. OK to install?
>>
>> Thanks.
>>
>> --
>> H.J.
>> ---
>> gcc/
>>
>> 2013-12-03 H.J. Lu
>>
>> PR target/59363
>> * config/i386/i386.c (emit_memset): Adjust destina
2013-12-03 Jonathan Wakely
* include/std/fstream (basic_filebuf::open): Use preformatted text
for table in Doxygen comment.
Tested x86_64-linux. Committed to trunk.
commit 8699304a9d3261d2b52636ee46c0203538de8fa1
Author: Jonathan Wakely
Date: Tue Dec 3 12:40:46 2013 +
On 11/29/2013 06:12 PM, Jakub Jelinek wrote:
> On Fri, Nov 29, 2013 at 06:07:38PM +0100, Bernd Schmidt wrote:
>> By what mechanism do you choose? This is unclear to me from what I've
>> seen. Does this involve user action, and what's the advantage of doing
>> it this way?
>
> See the 3 threads I'v
On Tue, Dec 3, 2013 at 1:48 PM, Bernd Edlinger
wrote:
> Hi Jeff,
>
> please find attached the patch (incl. test cases) for the unaligned read BUG
> that I found while investigating
> on PR#57748: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
>
> one test case is this one:
>
> pr57748-3.c:
> /
> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Tuesday, December 3, 2013 1:30 AM
> To: Jason Merrill; Iyer, Balaji V; Aldy Hernandez
> Cc: gcc-patches@gcc.gnu.org; r...@redhat.com; Jakub Jelinek
> Subject: Re: [PATCH] _Cilk_for for C and C++
>
> On 11/27/13 17:52,
Hi,
I almost forgot about this (rather simple) one. It falls in the category
"Mostly Harmless",
but it would be nice to have the bitregion_start/end consistent in all cases,
even when
it does currently not cause any mal-function.
this was:
> Subject: RE: [PATCH, PR 57748] Check for out of bound
On 03-12-13 13:49, Jakub Jelinek wrote:
On Thu, Nov 28, 2013 at 12:23:43AM +0100, Tom de Vries wrote:
Committed to trunk.
Also ok for 4.8 branch? It's a 4.8/4.9 regression.
Ok, but I guess you need to adjust your patch for 4.8 (tree_to_*
and tree_fits_* to host_integerp/tree_low_cst), so plea
On Tue, Dec 03, 2013 at 01:25:57PM +, Iyer, Balaji V wrote:
> > >> As you can tell, this is not how openmp handles a #pragma omp for loop.
> > >
> > > It's different in detail, but #pragma omp parallel for works very
> > > similarly: it creates a separate function for the body of the loop and
>
Ping?
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02351.html
Thanks,
Kyrill
On 26/11/13 09:44, Kyrill Tkachov wrote:
Ping?
Thanks,
Kyrill
On 19/11/13 17:04, Kyrill Tkachov wrote:
On 19/11/13 16:26, Joseph S. Myers wrote:
In any target header installed for user use, such as arm_acle.h, you
Hi Bernd,
I am working on offloading support for OpenMP4, so I'll try to share my vision
of how everything works and answer your questions.
GCC compiles host version of the code (as usual) and dumps Gimple, as it does
for LTO, but for offloading. Gimple IR is stored only for functions/variables
On Tue, Dec 3, 2013 at 2:10 PM, Richard Biener
wrote:
> On Tue, Dec 3, 2013 at 1:48 PM, Bernd Edlinger
> wrote:
>> Hi Jeff,
>>
>> please find attached the patch (incl. test cases) for the unaligned read BUG
>> that I found while investigating
>> on PR#57748: http://gcc.gnu.org/bugzilla/show_bug.
2013/11/23 Mike Stump :
> Richi has asked the we break the wide-int patch so that the individual port
> and front end maintainers can review their parts without have to go through
> the entire patch.This patch covers the avr port.
>
> Ok?
>
Ok.
Excuse my long delay. I was on vacation.
Pleas
> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Tuesday, December 3, 2013 8:40 AM
> To: Iyer, Balaji V
> Cc: Jeff Law; Jason Merrill; Aldy Hernandez; gcc-patches@gcc.gnu.org;
> r...@redhat.com
> Subject: Re: [PATCH] _Cilk_for for C and C++
>
> On Tue, Dec 03,
2013/11/18 Senthil Kumar Selvaraj :
> Ping!
>
> Regards
> Senthil
>
> On Mon, Nov 04, 2013 at 06:45:19PM +0530, Senthil Kumar Selvaraj wrote:
>> The AVR backend does not generate position independent code, yet it
>> happily accepts -fpic, -fPIC, -fpie and -fPIE. The generated code
>> doesn't change
> Date: Tue, 3 Dec 2013 14:51:21 +0100
> Subject: Re: [REPOST] Invalid Code when reading from unaligned zero-sized
> array
> From: richard.guent...@gmail.com
> To: bernd.edlin...@hotmail.de
> CC: l...@redhat.com; gcc-patches@gcc.gnu.org; ja...@redhat.com
>
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 Tue, Dec 03, 2013 at 02:01:17PM +, Iyer, Balaji V wrote:
> In Cilk_for you don't need to privatize any variables. I need to pass in
> the loop_count, the grain (if the user specifies one), the nested function
> and its context to a Cilk specific function:__cilkrts_cilk_for_64 (or 32).
> The
On Tue, Dec 3, 2013 at 2:10 PM, Richard Biener
wrote:
> On Tue, Dec 3, 2013 at 1:48 PM, Bernd Edlinger
> wrote:
>> Hi Jeff,
>>
>> please find attached the patch (incl. test cases) for the unaligned read BUG
>> that I found while investigating
>> on PR#57748: http://gcc.gnu.org/bugzilla/show_bug.
On Tue, 3 Dec 2013 12:23:11, Richard Biener wrote:
>
> On Tue, Dec 3, 2013 at 12:01 PM, Bernd Edlinger
> wrote:
>> Hi,
>>
>> This is my proposal for ulimately getting rid of the nasty
>> store_fixed_bit_field recursion.
>>
>> IMHO, the root of the recursion trouble is here:
>>
>> @@ -1007,12 +101
On Tue, Dec 3, 2013 at 1:50 PM, Yufeng Zhang wrote:
> On 12/03/13 06:48, Jeff Law wrote:
>>
>> On 12/02/13 08:47, Yufeng Zhang wrote:
>>>
>>> Ping~
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03360.html
>>
>>
>>>
>>> Thanks,
>>> Yufeng
>>>
>>> On 11/26/13 15:02, Yufeng Zhang wrote:
>
On Mon, Dec 2, 2013 at 10:39 PM, Kugan
wrote:
> ping
This patch needs to be approved by an ARM maintainer.
Ian
> On 27/11/13 15:30, Kugan wrote:
>> On 27/11/13 02:07, Richard Earnshaw wrote:
>>> On 23/11/13 01:54, Kugan wrote:
>>
>> [snip]
>>
+2013-11-22 Kugan Vivekanandarajah
+
>>
On Tue, Dec 3, 2013 at 1:32 AM, Richard Biener wrote:
> On Tue, 3 Dec 2013, Richard Biener wrote:
>
>>
>> Hi, I'm getting a bootstrap fail with Go with our custom patched
>> compiler (it adds that warning):
>>
>> 09:48 < richi> ../../../libgo/runtime/go-signal.c: In function
>>'run
if i did not already say so, this is fine.
kenny
On 12/02/2013 03:20 PM, Richard Sandiford wrote:
I noticed that there were still a couple of tests for zero precision.
This patch replaces them with asserts when handling separately-supplied
precisions and simply drops them when handling existing
> The patch does add a boolean "expand_reference" parameter to
> expand_expr_real and expand_expr_real_1. I pass true when I intend to use
> the returned memory context as an array reference, instead of a value. At
> places where mis-aligned values are extracted, I do not return a register
> with t
On Tue, Dec 3, 2013 at 3:50 PM, Jakub Jelinek wrote:
> On Mon, Dec 02, 2013 at 05:43:17PM +0100, Konstantin Serebryany wrote:
>> > No, so your patch doesn't regress anything. I can configure with
>> > --disable-libsanitizer to skip build of libsanitizer, although it
>> > would be nice to support R
>
> > case CILK_SPAWN_STMT:
> > gcc_assert
> > (fn_contains_cilk_spawn_p (cfun)
> > && lang_hooks.cilkplus.cilk_detect_spawn_and_unwrap (expr_p));
> > if (!seen_error ())
> > {
> > ret = (enum gimplify_status)
> >
On 12/3/2013, 6:54 AM, Marcus Shawcroft wrote:
On 2 December 2013 23:44, Vladimir Makarov wrote:
If somebody with the rights approves, I can commit it tomorrow.
2013-12-02 Vladimir Makarov
* config/aarch64/aarch64.c (aarch64_frame_pointer_required): Check
LR_REGNUM.
On Tue, Dec 03, 2013 at 07:18:14PM +0400, Konstantin Serebryany wrote:
> >> > No, so your patch doesn't regress anything. I can configure with
> >> > --disable-libsanitizer to skip build of libsanitizer, although it
> >> > would be nice to support RHEL5 derived long-term distributions.
> >> Ok, so
On 12/03/13 14:20, Richard Biener wrote:
On Tue, Dec 3, 2013 at 1:50 PM, Yufeng Zhang wrote:
On 12/03/13 06:48, Jeff Law wrote:
On 12/02/13 08:47, Yufeng Zhang wrote:
Ping~
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03360.html
Thanks,
Yufeng
On 11/26/13 15:02, Yufeng Zhang wrote:
On 11/29/2013 05:24 AM, Richard Biener wrote:
On Thu, Nov 28, 2013 at 6:11 PM, Kenneth Zadeck
wrote:
This patch does three things in wide-int:
1) it cleans up some comments.
2) removes a small amount of trash.
3) it changes the max size of the wide int from being 4x of
MAX_BITSIZE_MODE_ANY_INT
Hi Ramana/Richard,
Could you please help to review this patch?
Thanks in advance!
Kind regards,
Renlin Li
On 20/11/13 16:27, Renlin Li wrote:
Hi all,
This patch will make the arm back-end use vcvt for float to fixed
point conversions when applicable.
Test on arm-none-linux-gnueabi has bee
On 12/03/13 08:47, Jakub Jelinek wrote:
On Tue, Dec 03, 2013 at 07:18:14PM +0400, Konstantin Serebryany wrote:
No, so your patch doesn't regress anything. I can configure with
--disable-libsanitizer to skip build of libsanitizer, although it
would be nice to support RHEL5 derived long-term distr
Kenneth Zadeck writes:
> Index: tree-vrp.c
> ===
> --- tree-vrp.c(revision 205597)
> +++ tree-vrp.c(working copy)
> @@ -2611,22 +2611,28 @@ extract_range_from_binary_expr_1 (value_
>
>signop sign = TYPE_SIGN
Hi,
the patch below fixes a failure on the epiphany target where callers
and callees do not agree on registers for parameter passing because
they see different alignment of actual arguments and formal parameters
(there is some more information on this in bugzilla). The actual
arguments are SSA na
I attempted to build gcc-python-plugin against gcc trunk (r205358
specifically).
I ran into three kinds of issues:
(A) tracking down where declarations have landed in the new layout
(B) adding new headers to the list of those to be installed
(C) some porting due to "real" changes e.g. passes
Adhemerval noticed that the _TEXASR_INSTRUCTION_FETCH_CONFLICT and
_TEXASRU_INSTRUCTION_FETCH_CONFLICT HTM macros were misspelled.
I committed the following patch as obvious to fix them.
Peter
* config/rs6000/htmintrin.h (_TEXASR_INSTRUCTION_FETCH_CONFLICT): Fix
typo in macro name
On Dec 3, 2013, at 8:52 AM, Richard Sandiford
wrote:
> You probably already realise this, but for avoidance of doubt, Richard
> was also asking that we reduce MAX_BITSIZE_MODE_ANY_INT to 128 on x86_64,
> since that's the largest scalar_mode_supported_p mode.
Personally, I'd love to see scalar_mo
On Tue, 3 Dec 2013 16:14:49, Eric Botcazou wrote:
>
>> The patch does add a boolean "expand_reference" parameter to
>> expand_expr_real and expand_expr_real_1. I pass true when I intend to use
>> the returned memory context as an array reference, instead of a value. At
>> places where mis-aligned v
On 11/30/13 10:15, Iyer, Balaji V wrote:
Hello Jakub,
I was looking at my elemental function for C patch that I fixed up and
send as requested by Aldy, and I saw two changes there that were used for C and
C++ and they were pretty obvious. Here are the changes. Can I just commit them?
On Dec 2, 2013, at 10:26 PM, Jeff Law wrote:
> On 11/27/13 17:13, Cesar Philippidis wrote:
>>
>> I looked into adding support for incremental DF scanning from df*.[ch]
>> in combine but there are a couple of problems. First of all, combine
>> does its own DF analysis. It does so because its usage
On 12/03/13 11:40, Bernd Edlinger wrote:
To me it does not feel like a hack at all, if the expansion needs to know in
what
context the result will be used, if it is in an LHS or in a RHS or if the
address of
the memory is needed.
Expansion needs some context and it's currently passed into ex
On 12/03/13 08:52, Yufeng Zhang wrote:
I still don't like it. It's using the wrong and too expensive tools
to do
stuff. What kind of bases are we ultimately interested in? Browsing
the code it looks like we're having
/* Base expression for the chain of candidates: often, but not
al
On Fri, 2013-11-29 at 15:01 +0300, Kirill Yukhin wrote:
> Hello,
> On 20 Nov 18:37, Kirill Yukhin wrote:
> > Hello,
> > Patch in the bottom fixes PR52731.
> > Is it ok for trunk?
> Ping?
>
> --
> Thanks, K
OK.
Steve Ellcey
sell...@mips.com
On 12/03/2013 01:52 PM, Mike Stump wrote:
On Dec 2, 2013, at 10:26 PM, Jeff Law wrote:
On 11/27/13 17:13, Cesar Philippidis wrote:
I looked into adding support for incremental DF scanning from df*.[ch]
in combine but there are a couple of problems. First of all, combine
does its own DF analysi
On 12/03/13 12:25, Kenneth Zadeck wrote:
On 12/03/2013 01:52 PM, Mike Stump wrote:
On Dec 2, 2013, at 10:26 PM, Jeff Law wrote:
On 11/27/13 17:13, Cesar Philippidis wrote:
I looked into adding support for incremental DF scanning from df*.[ch]
in combine but there are a couple of problems. Fir
On 12/03/13 09:53, Martin Jambor wrote:
Hi,
the patch below fixes a failure on the epiphany target where callers
and callees do not agree on registers for parameter passing because
they see different alignment of actual arguments and formal parameters
(there is some more information on this in b
> This patches gen_compile_unit_die to use the DW_LANG_D DWARF language
> code for D. Is in relation to some other D language fixes that are
> going to be submitted to gdb.
Is this for a private front end? I'm not aware of any front ends that
set the language name to "GNU D".
Since it's so trivi
On 12/03/13 06:25, Iyer, Balaji V wrote:
I understand you both now. Let me look into the OMP routines and see what it is
doing and see how I can port it to _Cilk_for.
Thanks. I know it's a bit of a pain, but part what's driving the desire
to share is to reduce the long term maintenance cost
On Tue, Nov 19, 2013 at 10:07:00AM -0500, Jason Merrill wrote:
> On 11/18/2013 11:39 AM, Marek Polacek wrote:
> >+init = fold_build2 (COMPOUND_EXPR, TREE_TYPE (init),
> >+ubsan_instrument_reference (input_location, init),
> >+init);
>
> This look
On 12/02/13 23:39, Kugan wrote:
+2013-11-27 Kugan Vivekanandarajah
+
+ * config/arm/bpapi-lib.h (TARGET_HAS_NO_HW_DIVIDE): Define for
+ architectures that does not have hardware divide instruction.
+ i.e. architectures that does not define __ARM_ARCH_EXT_IDIV__.
+
Is this
On 12/02/13 13:10, Marek Polacek wrote:
We triggered an assert on attached testcase, because when building the
compound literal with empty initial value complete_array_type returns
3, but we assert it returns 0. It returns 3 only in the pedantic mode,
where empty initializer braces are forbidden
On 11/28/13 15:58, Jakub Jelinek wrote:
+ for (i = 0; i < omp_clause_num_ops[OMP_CLAUSE_CODE (expr)]; i++)
+stream_write_tree (ob, OMP_CLAUSE_OPERAND (expr, i), ref_p);
+ if (OMP_CLAUSE_CODE (expr) == OMP_CLAUSE_REDUCTION)
+{
+ /* We don't stream these right now, handle it if stre
On 11/28/13 16:00, Jakub Jelinek wrote:
Hi!
And here is second part of the fixes. Still, the vect-simd-clone-12.c
testcase fails with -flto -flto-partition=1to1, so there is further work to
do, but at least all current test succeed and actually use SIMD elementals
when they should. Bootstrappe
On Tue, Dec 03, 2013 at 01:03:43PM -0700, Jeff Law wrote:
> On 12/02/13 13:10, Marek Polacek wrote:
> >We triggered an assert on attached testcase, because when building the
> >compound literal with empty initial value complete_array_type returns
> >3, but we assert it returns 0. It returns 3 only
On 11/28/13 16:09, Jakub Jelinek wrote:
On Wed, Nov 27, 2013 at 04:10:16PM +0100, Richard Biener wrote:
As you pinged this ... can you re-post a patch with changelog that
includes the followups as we decided?
Ok, here is the updated patch against latest trunk with the follow-ups
incorporated.
On Tue, Dec 03, 2013 at 01:11:08PM -0700, Jeff Law wrote:
> On 11/28/13 15:58, Jakub Jelinek wrote:
> + for (i = 0; i < omp_clause_num_ops[OMP_CLAUSE_CODE (expr)]; i++)
> >+stream_write_tree (ob, OMP_CLAUSE_OPERAND (expr, i), ref_p);
> >+ if (OMP_CLAUSE_CODE (expr) == OMP_CLAUSE_REDUCTION)
>
On 12/03/13 13:14, Jakub Jelinek wrote:
On Tue, Dec 03, 2013 at 01:11:08PM -0700, Jeff Law wrote:
On 11/28/13 15:58, Jakub Jelinek wrote:
+ for (i = 0; i < omp_clause_num_ops[OMP_CLAUSE_CODE (expr)]; i++)
+stream_write_tree (ob, OMP_CLAUSE_OPERAND (expr, i), ref_p);
+ if (OMP_CLAUSE_COD
Yufeng Zhang wrote:
>On 12/03/13 14:20, Richard Biener wrote:
>> On Tue, Dec 3, 2013 at 1:50 PM, Yufeng Zhang
>wrote:
>>> On 12/03/13 06:48, Jeff Law wrote:
On 12/02/13 08:47, Yufeng Zhang wrote:
>
> Ping~
>
> http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03360.html
On Tue, 3 Dec 2013 12:16:39, Jeff Law wrote:
>
> On 12/03/13 11:40, Bernd Edlinger wrote:
>>>
>>
>> To me it does not feel like a hack at all, if the expansion needs to know in
>> what
>> context the result will be used, if it is in an LHS or in a RHS or if the
>> address of
>> the memory is need
On 11/27/13 01:13, Marek Polacek wrote:
On Fri, Nov 22, 2013 at 10:54:16AM +0100, Marek Polacek wrote:
Hi!
Working virtually out of Pago Pago.
The following is the implementation of the signed integer overflow
checking for the UndefinedBehaviorSanitizer. I wrote some of the
generic bits; Jaku
Hi,
The arguments to --with-multilib-list for AARCH64 are exclusive but currently
is being treated as ones which are not. This causes problems in that we get
four library sets with --with-multilib-list=lp64,ilp32: empty, lp64, ilp32,
lp64/ilp32. The first and last one does not make sense an
Hi,
With ILP32 AARCH64, Pmode (DImode) != ptrmode (SImode) so the variable decl
has a mode of SImode while the register is DImode. So the target that gets
passed down to expand_builtin_thread_pointer is NULL as expand does not
know how to get a subreg for a pointer type.
This fixes the problem
This patch set adds ILP32 support to GCC for GNU/Linux.
A patch to size and pointer difference types for ILP32.
A middle-end to fix an ICE with __builtin_thread_pointer with ILP32.
A patch which fixes multi-lib list as the arguments to --with-multilib-list
are exclusive.
A patch which adds th
As mentioned in http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02228.html, this
implements the trap pattern according to what was decided which brk should be
used.
OK? Built and tested on aarch64-elf with no regressions. Also built a glibc
for aarch64-linux-gnu with this patch included (LP64).
While compiling some programs, GCC and glibc (and newlib)'s definitions of
size_t
were not agreeing and causing format warnings to happen. The simple testcase
for this is:
#include
#include
int main(void)
{
ssize_t t = 0x1;
printf("%zd\n", t);
return 0;
}
- CUT -
OK? Built an
Hi,
With ILP32, some simple usage of TLS variables causes an unrecognizable
instruction due to needing to use SImode for loading pointers from memory.
This fixes the three (tlsie_small, tlsle_small, tlsdesc_small) patterns to
support SImode for pointers.
OK? Build and tested on aarch64-elf with
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? Build and tested for aarch64-linux-gnu with
1 - 100 of 133 matches
Mail list logo