On Tue, Dec 3, 2013 at 2:05 AM, H.J. Lu hongjiu...@intel.com 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 hongjiu...@intel.com
On Mon, 2 Dec 2013, Kenneth Zadeck wrote:
On 12/02/2013 03:34 PM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com 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
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);
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
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 ago
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_conditional_move will be
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
Jeff Law l...@redhat.com 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
On Mon, 2 Dec 2013 15:42:48, Richard Biener wrote:
On Wed, Nov 20, 2013 at 11:48 AM, Bernd Edlinger
bernd.edlin...@hotmail.de 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
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 regex is a new feature, I think we have some leeway
in terms of timing, but definitely we can't commit invasive
.. I meant mid of *January* of course.
Paolo.
On Tue, Dec 3, 2013 at 10:47 AM, Bernd Edlinger
bernd.edlin...@hotmail.de wrote:
On Mon, 2 Dec 2013 15:42:48, Richard Biener wrote:
On Wed, Nov 20, 2013 at 11:48 AM, Bernd Edlinger
bernd.edlin...@hotmail.de wrote:
Hello Richard,
as a follow-up patch to the bit-fields patch(es), I wanted to
On Tue, Dec 3, 2013 at 10:59 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Tue, Dec 3, 2013 at 10:47 AM, Bernd Edlinger
bernd.edlin...@hotmail.de wrote:
On Mon, 2 Dec 2013 15:42:48, Richard Biener wrote:
On Wed, Nov 20, 2013 at 11:48 AM, Bernd Edlinger
bernd.edlin...@hotmail.de
On Tue, Dec 3, 2013 at 4:47 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
Great. Consider that we are now in Stage 3, until mid of February.
Considering that regex is a new feature, I think we have some leeway in
terms of timing, but definitely we can't commit invasive changes not fixing
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
bernd.edlin...@hotmail.de wrote:
On Mon, 2 Dec 2013 15:42:48, Richard Biener wrote:
On Wed, Nov 20, 2013 at 11:48 AM, Bernd Edlinger
bernd.edlin...@hotmail.de wrote:
Hello Richard,
as a
On Mon, Dec 2, 2013 at 6:38 PM, Xinliang David Li davi...@google.com 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
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 there
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
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:
On Tue, Dec 3, 2013 at 12:01 PM, Bernd Edlinger
bernd.edlin...@hotmail.de 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
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 like this,
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 not gate
On 2 December 2013 23:44, Vladimir Makarov vmaka...@redhat.com wrote:
If somebody with the rights approves, I can commit it tomorrow.
2013-12-02 Vladimir Makarov vmaka...@redhat.com
* config/aarch64/aarch64.c (aarch64_frame_pointer_required): Check
LR_REGNUM.
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 did
On Tue, Dec 3, 2013 at 12:45 AM, Michael Zolotukhin
michael.v.zolotuk...@gmail.com 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
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 hongjiu...@intel.com
PR target/59363
* config/i386/i386.c (emit_memset): Adjust destination address
after gen_strset.
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
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
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
On Tue, Dec 3, 2013 at 4:41 AM, Jan Hubicka hubi...@ucw.cz 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 hongjiu...@intel.com
PR target/59363
* config/i386/i386.c (emit_memset): Adjust
2013-12-03 Jonathan Wakely jwakely@gmail.com
* 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 jwakely@gmail.com
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've
On Tue, Dec 3, 2013 at 1:48 PM, Bernd Edlinger
bernd.edlin...@hotmail.de 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:
-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, Jason
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 bounds
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
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
then
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
richard.guent...@gmail.com wrote:
On Tue, Dec 3, 2013 at 1:48 PM, Bernd Edlinger
bernd.edlin...@hotmail.de wrote:
Hi Jeff,
please find attached the patch (incl. test cases) for the unaligned read BUG
that I found while investigating
on
2013/11/23 Mike Stump mikest...@comcast.net:
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
-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 at
2013/11/18 Senthil Kumar Selvaraj senthil_kumar.selva...@atmel.com:
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
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
On Thu, Nov 21, 2013 at 9:57 PM, Alan Modra amo...@gmail.com 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.
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
richard.guent...@gmail.com wrote:
On Tue, Dec 3, 2013 at 1:48 PM, Bernd Edlinger
bernd.edlin...@hotmail.de wrote:
Hi Jeff,
please find attached the patch (incl. test cases) for the unaligned read BUG
that I found while investigating
on
On Tue, 3 Dec 2013 12:23:11, Richard Biener wrote:
On Tue, Dec 3, 2013 at 12:01 PM, Bernd Edlinger
bernd.edlin...@hotmail.de 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:
@@
On Tue, Dec 3, 2013 at 1:50 PM, Yufeng Zhang yufeng.zh...@arm.com 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/26/13 12:45,
On Mon, Dec 2, 2013 at 10:39 PM, Kugan
kugan.vivekanandara...@linaro.org 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
On Tue, Dec 3, 2013 at 1:32 AM, Richard Biener rguent...@suse.de 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
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
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 the
On Tue, Dec 3, 2013 at 3:50 PM, Jakub Jelinek ja...@redhat.com 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
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 vmaka...@redhat.com wrote:
If somebody with the rights approves, I can commit it tomorrow.
2013-12-02 Vladimir Makarov vmaka...@redhat.com
* config/aarch64/aarch64.c
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 this does not
On 12/03/13 14:20, Richard Biener wrote:
On Tue, Dec 3, 2013 at 1:50 PM, Yufeng Zhangyufeng.zh...@arm.com 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,
On 11/29/2013 05:24 AM, Richard Biener wrote:
On Thu, Nov 28, 2013 at 6:11 PM, Kenneth Zadeck
zad...@naturalbridge.com 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
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
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
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
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
On Dec 3, 2013, at 8:52 AM, Richard Sandiford rsand...@linux.vnet.ibm.com
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,
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 values are
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 l...@redhat.com 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
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
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
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 l...@redhat.com 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
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 l...@redhat.com 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
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
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 trivial,
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 looks like
On 12/02/13 23:39, Kugan wrote:
+2013-11-27 Kugan Vivekanandarajah kug...@linaro.org
+
+ * 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
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
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
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.
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
Yufeng Zhang yufeng.zh...@arm.com wrote:
On 12/03/13 14:20, Richard Biener wrote:
On Tue, Dec 3, 2013 at 1:50 PM, Yufeng Zhangyufeng.zh...@arm.com
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 needed.
Expansion
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;
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
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
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 stdio.h
#include stdint.h
int main(void)
{
ssize_t t = 0x1;
printf(%zd\n, t);
return 0;
}
- CUT -
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
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
On Tue, Dec 03, 2013 at 07:18:14PM +0400, Konstantin Serebryany wrote:
==2738==AddressSanitizer CHECK failed:
../../../../libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:260
((*tls_addr + *tls_size)) = ((*stk_addr + *stk_size)) (0x2af8df1bc240,
0x2af8df1bc000)
which clearly is
On 12/03/13 20:35, Richard Biener wrote:
Yufeng Zhangyufeng.zh...@arm.com wrote:
On 12/03/13 14:20, Richard Biener wrote:
On Tue, Dec 3, 2013 at 1:50 PM, Yufeng Zhangyufeng.zh...@arm.com
wrote:
On 12/03/13 06:48, Jeff Law wrote:
On 12/02/13 08:47, Yufeng Zhang wrote:
Ping~
On Tue, 2013-12-03 at 21:35 +0100, Richard Biener wrote:
Yufeng Zhang yufeng.zh...@arm.com wrote:
On 12/03/13 14:20, Richard Biener wrote:
On Tue, Dec 3, 2013 at 1:50 PM, Yufeng Zhangyufeng.zh...@arm.com
wrote:
On 12/03/13 06:48, Jeff Law wrote:
On 12/02/13 08:47, Yufeng Zhang wrote:
1 - 100 of 129 matches
Mail list logo
