Another somewhat early PING**2
On June 29, 2014, Tobias Burnus wrote:
This patch fixes some issues with polymorphic coarrays. I still have
to fix at least one issue.
Fixed by the patch:
a) The temporary pointer generated with SELECT TYPE has to be a
coarray. That's fixed with the resolve.c
Andrew,
Thanks for the input. Patch is updated with your codes. In addition,
add cstorecc4 and 4 test cases. So it can optimized the following
example
int foo (int a, int b)
{
return a 0 b 7;
}
to:
cmpw0, wzr
ccmpw1, #6, #9, gt
csetw0, le
Bootstrap and no make
On Thu, Jul 3, 2014 at 3:02 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Thu, Jul 3, 2014 at 2:43 PM, FX fxcoud...@gmail.com wrote:
Here’s an updated patch, providing support for underflow control in the
IEEE_ARITHMETIC module, for x86/x86_64 targets and alpha-glibc.
Bootstrapped and
Hi there,
I am thinking to provide the update below on our main page.
Let me know if there are any changes you'd like to see.
Also, for that page having 2-3(-4) words as a short title are necessary.
What would be appropriate here? Fortran IEEE intrinsic modules?
Gerald
Index: index.html
On July 3, 2014 10:47:52 PM CEST, Mark Wielaard m...@redhat.com wrote:
On Thu, 2014-07-03 at 22:14 +0200, Jakub Jelinek wrote:
On Thu, Jul 03, 2014 at 10:04:35PM +0200, Mark Wielaard wrote:
On Thu, 2014-07-03 at 21:52 +0200, Richard Biener wrote:
On July 3, 2014 8:38:14 PM CEST, Jakub
Also, for that page having 2-3(-4) words as a short title are necessary.
What would be appropriate here? Fortran IEEE intrinsic modules”?
Sounds good to me.
FX
On July 3, 2014 8:47:36 PM CEST, Jakub Jelinek ja...@redhat.com wrote:
Hi!
update_ssa that expand_thunk calls, if it needs to change anything,
computes CDI_DOMINATORS, but we assert that dominators are not computed
when we release e.g. an unused thunk.
Fixed thusly, bootstrapped/regtested on
On July 3, 2014 8:44:28 PM CEST, Jakub Jelinek ja...@redhat.com wrote:
Hi!
The rhs1 of CONVERT_EXPR_CODE_P doesn't have to be a SSA_NAME, can be
e.g.
invariant like ADDR_EXPR of a var, but ifcombine didn't think about
that
possibility.
Fixed thusly, bootstrapped/regtested on x86_64-linux and
Hi,
BLOCK_SUPERCONTEXT for normal blocks leads all the way to FUNCTOIN_DECL. This
is not the case of some
automatically generated functions, like one for cilk. I think it is bug. This
patch fixes cilk, I will
look for other cases if that looks OK.
Bootstrapped/regtested x86_64-linux
Honza
On 2014-06-30 15:03, Marek Polacek wrote:
On Fri, Jun 27, 2014 at 08:49:24AM +0200, Marek Polacek wrote:
On Fri, Jun 27, 2014 at 08:36:38AM +0200, Sebastian Huber wrote:
Thanks for your patience. It would be nice if this can be applied to GCC
4.9 as well.
Can someone please commit this for
On Wed, Jun 18, 2014 at 10:16 AM, Terry Guo terry@arm.com wrote:
-Original Message-
From: Richard Earnshaw
Sent: Wednesday, June 18, 2014 4:31 PM
To: Terry Guo
Cc: gcc-patches@gcc.gnu.org; Ramana Radhakrishnan
Subject: Re: [Patch, GCC/Thumb-1]Mishandle the label type insn in
On 04/07/14 10:36, Bin.Cheng wrote:
On Wed, Jun 18, 2014 at 10:16 AM, Terry Guo terry@arm.com wrote:
-Original Message-
From: Richard Earnshaw
Sent: Wednesday, June 18, 2014 4:31 PM
To: Terry Guo
Cc: gcc-patches@gcc.gnu.org; Ramana Radhakrishnan
Subject: Re: [Patch,
On Fri, Jul 4, 2014 at 10:36 AM, Bin.Cheng amker.ch...@gmail.com wrote:
On Wed, Jun 18, 2014 at 10:16 AM, Terry Guo terry@arm.com wrote:
-Original Message-
From: Richard Earnshaw
Sent: Wednesday, June 18, 2014 4:31 PM
To: Terry Guo
Cc: gcc-patches@gcc.gnu.org; Ramana
Setting TYPE_PRECISION is mostly useless, because most of gcc assumes
it's the same as TYPE_SIZE and ignores it.
Then you need to change that and not TYPE_SIZE.
It seems to work just fine in testing, and I'm trying to make it
non-fundamental.
I'm very skeptical... In any case, having a
On 04/07/14 05:59, lin zuojian wrote:
Hi,
This crash is due to fail to consider the exception situation that
the insn variable may not be a insn at all.
arm.c (thumb1_reorg): if the
selected insn is not a insn, continue to next bb.
---
gcc/config/arm/arm.c | 2 +-
1 file
I don't doubt it, because I've been fighting these assumptions for years.
The fight needs to be resumed/sped up, that's clearly the right thing to do.
Then please provide a very good idea for how to teach gcc about true
20-bit types in a system with 8-bit memory and 16-bit words.
Thanks Richard,
I didn't aware that patch.
--
Lin Zuojian
Hi,
This patch is the preparation for subsquent patches of modules
implementation. In addition to create several empty source files,
we also need to modify config.gcc and provide t-nds32 makefile fragment.
Committed as Rev.212280.
https://gcc.gnu.org/r212280
Best regards,
jasonwucj
Hi,
There are many helper functions implemented in nds32.c to
deal with interrupt service routine code generation.
We move all of them into nds32-isr.c module.
Committed as Rev.212281.
https://gcc.gnu.org/r212281
Best regards,
jasonwucj
Hi,
For supporting target specific builtin functions,
we use an individual nds32-intrinsic.c module to implement
essential and helpler functions.
Committed as Rev.212282.
https://gcc.gnu.org/r212282
Best regards,
jasonwucj
I noticed that although configure on aarch64 handles --with-arch and
--with-cpu, they aren't passed on to the compilation -- instead you just
get whatever the internal default is in the compiler back-end. This
patch fixes that by wiring up the missing logic.
2014-07-04 Richard Earnshaw
2014-07-04 18:47 GMT+08:00 Chung-Ju Wu jasonw...@gmail.com:
Hi,
This patch is the preparation for subsquent patches of modules
implementation. In addition to create several empty source files,
we also need to modify config.gcc and provide t-nds32 makefile fragment.
Committed as Rev.212280.
2014-07-04 18:48 GMT+08:00 Chung-Ju Wu jasonw...@gmail.com:
Hi,
There are many helper functions implemented in nds32.c to
deal with interrupt service routine code generation.
We move all of them into nds32-isr.c module.
Committed as Rev.212281.
https://gcc.gnu.org/r212281
Sorry I
2014-07-04 18:50 GMT+08:00 Chung-Ju Wu jasonw...@gmail.com:
Hi,
For supporting target specific builtin functions,
we use an individual nds32-intrinsic.c module to implement
essential and helpler functions.
Committed as Rev.212282.
https://gcc.gnu.org/r212282
Sorry I forgot to attach
Hi,
Attached is a patch that implements
* Prefetch with immediate offset in the range 0 to 32760 (multiple of 8).
Added a predicate for this.
* Prefetch with immediate offset - in the range -256 to 255 (Gets
generated only when we have a negative offset. Generates prfum
Hi,
Many external functions are used in predicates and constraints checking.
We move all of them into nds32-predicates.c module so that we
can easily maintain those implementation in the future.
Committed as Rev.212283.
https://gcc.gnu.org/r212283
Best regards,
jasonwucj
Hi,
We provide a nds32-cost.c module to maintain some cost implementation
required by target hooks and macros. Currently we only migrate
nds32_rtx_costs()
and nds32_address_cost() into the module.
Committed as Rev.212284.
https://gcc.gnu.org/r212284
Best regards,
jasonwucj
Hi,
The module is prepared for future implementation of pipeline models.
In this patch we only add a few comment to describe its purpose.
Committed as Rev.212285.
https://gcc.gnu.org/r212285
Best regards,
jasonwucj
0006-PATCH-06-Preparation-of-nds32-pipelines-auxiliary.c-.patch
Hi,
The multiple load/store instructions are provided by nds32 target and
some memory access behaviors are able to utilize such instuctions.
We use nds32-memory-manipulation.c module to hold those memory related
implementation.
Committed as Rev.212287.
https://gcc.gnu.org/r212287
Best
Hi,
There is a target specific optimization, called fp-as-gp optimization,
in the nds32 port. We are planning to make it as an individual pass.
By now we just move related implementation into nds32-fp-as-gp.c module.
Committed as Rev.212288.
https://gcc.gnu.org/r212288
Best regards,
Hi, all,
In the nds32 port, we are expecting the implementation in nds32.c
is going to gradually grow up. For the sake of future maintenance,
we decide to provide individual modules and then migrate some
implementation from nds32.c into the modules.
The following is a series of patches:
On Thu, Jul 3, 2014 at 10:57 AM, Evgeny Stupachenko evstu...@gmail.com wrote:
The following patch should fix 61618
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61618
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 8046c67..2cffcef 100644
--- a/gcc/config/i386/i386.c
+++
On Thu, Jul 3, 2014 at 11:53 AM, Evgeny Stupachenko evstu...@gmail.com wrote:
The expand_vec_perm_palignr is similar for SSSE3 and AVX2 cases,
but AVX2 requires more instructions to complete the scheme.
The patch below adds AVX2 support for six instructions, leaving SSSE3 for two.
Is it ok?
Hi Rainer,
All contributions to libsanitizer should go via LLVM repository.
See https://code.google.com/p/address-sanitizer/wiki/HowToContribute
The smaller the patches the faster they will come through.
If you can set up a public build bot it will *immensely* simplify many things.
(see more
Hello Nicholas,
Nicholas Ormrod nicholas.orm...@hotmail.com writes:
I found time this morning to run your changes through our system. I
patched our gcc-4.8.1 with your latest change, and ran it through our
folly testsuite.
Thanks!
One thing that I immediately noticed was that this
-Original Message-
From: Bin.Cheng [mailto:amker.ch...@gmail.com]
Sent: Wednesday, July 02, 2014 1:46 PM
To: Ramana Radhakrishnan
Cc: Bin Cheng; Richard Earnshaw; gcc-patches
Subject: Re: [PATCH ARM]Handle REG addressing mode in
output_move_neon explicitly
On Wed, Jul 2, 2014
Hi Konstantin,
All contributions to libsanitizer should go via LLVM repository.
See https://code.google.com/p/address-sanitizer/wiki/HowToContribute
The smaller the patches the faster they will come through.
ok. I'll see how to split up the patches. Some parts are completely
trivial in that
2014-07-04 Evgeny Stupachenko evstu...@gmail.com
* config/i386/i386.c (expand_vec_perm_palignr): Extend to use AVX2
PALINGR instruction.
* config/i386/i386.c (ix86_expand_vec_perm_const_1): Add palignr try
for AVX2.
On Fri, Jul 4, 2014 at 3:22 PM, Uros Bizjak
On Fri, Jul 4, 2014 at 10:44 AM, Ramana Radhakrishnan
ramana@googlemail.com wrote:
On Fri, Jul 4, 2014 at 10:36 AM, Bin.Cheng amker.ch...@gmail.com wrote:
On Wed, Jun 18, 2014 at 10:16 AM, Terry Guo terry@arm.com wrote:
-Original Message-
From: Richard Earnshaw
Sent:
2014-07-04 Evgeny Stupachenko evstu...@gmail.com
* config/i386/i386.c (expand_vec_perm_pblendv): Disable for AVX.
On Fri, Jul 4, 2014 at 3:20 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Thu, Jul 3, 2014 at 10:57 AM, Evgeny Stupachenko evstu...@gmail.com
wrote:
The following patch
On Fri, Jul 4, 2014 at 4:38 PM, Rainer Orth r...@cebitec.uni-bielefeld.de
wrote:
Hi Konstantin,
All contributions to libsanitizer should go via LLVM repository.
See https://code.google.com/p/address-sanitizer/wiki/HowToContribute
The smaller the patches the faster they will come through.
Roman Gareev gareevro...@gmail.com writes:
It seems the patch1/patch2 files you attach have the Content-Type:
application/octet-stream. This makes it impossible to view them inline.
Could you send them as text files? Just calling them patch1.patch or
patch1.txt should make this work.
Yes,
On Fri, Jul 4, 2014 at 2:49 PM, Evgeny Stupachenko evstu...@gmail.com wrote:
2014-07-04 Evgeny Stupachenko evstu...@gmail.com
* config/i386/i386.c (expand_vec_perm_pblendv): Disable for AVX.
Please mention PR target/61618 above.
The following patch should fix 61618
This is the rebased patch, though the original one doesn't conflict with
latest trunk. Is it OK?
Ok.
Ramana
Thanks,
bin
[ was: Re: combination of read/write and earlyclobber constraint modifier on
gcc@ ]
On 03-07-14 00:42, Jeff Law wrote:
Based on various followups (public private), let's go with the clarification
above. Richard E. explicitly added support for this in the mid/late 90s as an
optimization for
No regressions on aarch64-none-elf; new tests passing on aarch64-none-elf,
arm-none-eabi, x86_64-unknown-linux-gnu:
NA-PASS gcc.dg/vect/vect-singleton_1.c (test for warnings, line 20)
NA-PASS gcc.dg/vect/vect-singleton_1.c (test for excess errors)
gcc/ChangeLog:
*
Applied.
Gerald
Index: git/gitweb_config.perl
===
RCS file: /cvs/gcc/wwwdocs/htdocs/git/gitweb_config.perl,v
retrieving revision 1.1
diff -u -r1.1 gitweb_config.perl
--- git/gitweb_config.perl 18 Mar 2008 02:07:15 -
Patch here.
Alan Lawrence wrote:
No regressions on aarch64-none-elf; new tests passing on aarch64-none-elf,
arm-none-eabi, x86_64-unknown-linux-gnu:
NA-PASS gcc.dg/vect/vect-singleton_1.c (test for warnings, line 20)
NA-PASS gcc.dg/vect/vect-singleton_1.c (test for excess errors)
On Fri, Jun 27, 2014 at 04:32:19PM +0100, Tejas Belagod wrote:
+/* Internal scalar builtin types. These types are used to support
+ neon intrinsic builtins. They are _not_ user-visible types. Therefore
+ the mangling for these types are implementation defined. */
+const char
Ping.
Original Message
Subject:[PATCH][Ping v2] Add patch for debugging compiler ICEs
Date: Thu, 26 Jun 2014 19:46:08 +0400
From: Maxim Ostapenko m.ostape...@partner.samsung.com
To: GCC Patches gcc-patches@gcc.gnu.org
CC: Yury Gribov y.gri...@samsung.com,
On 24 June 2014 09:45, James Greenhalgh james.greenha...@arm.com wrote:
2014-06-20 James Greenhalgh james.greenha...@arm.com
* config/aarch64/aarch64-simd.md (move_lo_quad_internal_mode): New.
(move_lo_quad_internal_be_mode): Likewise.
(move_lo_quad_mode): Convert
On 4 July 2014 14:58, Alan Lawrence alan.lawre...@arm.com wrote:
No regressions on aarch64-none-elf; new tests passing on aarch64-none-elf,
arm-none-eabi, x86_64-unknown-linux-gnu:
NA-PASS gcc.dg/vect/vect-singleton_1.c (test for warnings, line 20)
NA-PASS gcc.dg/vect/vect-singleton_1.c (test
On Mon, Jun 02, 2014 at 04:21:14PM +0100, Maxim Ostapenko wrote:
Hi,
A years ago there was a discussion
(https://gcc.gnu.org/ml/gcc-patches/2004-01/msg02437.html) about debugging
compiler ICEs that resulted in a patch from Jakub, which dumps
useful information into temporary file, but for
On Fri, Jul 04, 2014 at 04:13:31PM +0100, James Greenhalgh wrote:
On Mon, Jun 02, 2014 at 04:21:14PM +0100, Maxim Ostapenko wrote:
Hi,
A years ago there was a discussion
(https://gcc.gnu.org/ml/gcc-patches/2004-01/msg02437.html) about debugging
compiler ICEs that resulted in a patch
On Mon, Jun 23, 2014 at 06:43:20PM +0100, Jan Hubicka wrote:
On Mon, 23 Jun 2014, James Greenhalgh wrote:
Hi,
pr61510 is a case where cgraphunit.c::analyze_functions can end up
dereferencing a NULL pointer. This is, to me, the obvious way to avoid
dereferencing NULL.
Hi all,
-mwords-little-endian was deprecated in GCC 4.7. This patch removes the
option and associated machinery and documentation.
Tested armeb-none-eabi and saw no regressions.
Ok for trunk?
Thanks,
Kyrill
2014-07-04 Kyrylo Tkachov kyrylo.tkac...@arm.com
* config/arm/arm.opt
Dear Tobias,
This looks absolutely fine to me - good for trunk.
Thanks for the patch and for the overall co-array effort.
Paul
On 4 July 2014 08:02, Tobias Burnus bur...@net-b.de wrote:
Another somewhat early PING**2
On June 29, 2014, Tobias Burnus wrote:
This patch fixes some issues
On Thu, 3 Jul 2014, Kirill Yukhin wrote:
Hello Marc,
On 28 Jun 12:42, Marc Glisse wrote:
It would enable a number of optimizations, like constant
propagation, FMA contraction, etc. It would also allow us to remove
several builtins.
This should be main motivation for replacing built-ins.
But
Hi!
This patch adds -fsanitize=alignment support, part of -fsanitize=undefined,
which will complain about misaligned accesses (those where the compiler
isn't told it is less than naturally aligned access, such as with packed
struct accesses).
In addition to that it adds instrumentation of
On Mon, Jun 23, 2014 at 04:40:43PM +0200, Richard Biener wrote:
Can we instead refactor expmed.c to avoid allocating rtx_def directly?
Like by using rtx in init_expmed_rtl and allocating from an obstack
(or not care and GC-allocate anyway).
So like this? Bootstrapped/regtested on x86_64-linux
On Wed, 2014-06-25 08:55:57 -0700, augustine.sterl...@gmail.com
augustine.sterl...@gmail.com wrote:
On Tue, Jun 24, 2014 at 10:20 PM, Jan Hubicka hubi...@ucw.cz wrote:
This is the xtensa fallout, see
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=272418
g++ -c -g
On 07/02/2014 01:18 PM, Jan Hubicka wrote:
We propagate types from places we know instances are created across pointers
passed to functions. Once non-POD type is created at a given memory
location,
one can not change its type by placement_new into something else.
Hmm. If the memory
62 matches
Mail list logo
