Hi!
Sorry for the late answer -- I've been on sick leave, and just now
returning to work. Julian, would you please have a look at the following
issues?
In r219682, I have committed to trunk our current set of OpenACC changes,
which we had prepared on gomp-4_0-branch. Thanks to everyone
FX fxcoud...@gmail.com writes:
The default BOOT_CFLAGS are: -O2 -g -mdynamic-no-pic
the libiberty pic build appends: -fno-common (and not even -fPIC) [NB
-fPIC _won't_ override -mdynamic-no-pic, so that's not a simple way out]
This means that the PIC library is being built with non-pic
On 20 January 2015 at 15:28, Christophe Lyon christophe.l...@linaro.org wrote:
On 16 January 2015 at 17:24, Tejas Belagod tejas.bela...@arm.com wrote:
+VECT_VAR_DECL(expected,poly,8,8) [] = { 0x33, 0x33, 0x33, 0x33,
+ 0x33, 0x33, 0x33, 0x33 };
On Mon, Jan 26, 2015 at 01:14:39PM +0100, Tobias Burnus wrote:
The question is why I didn't see the nonsense in the test suite. It
doesn't seem to be tested for in gcc/testsuite/gfortran.dg/; it might be
tested in libgomp/testsuite/ - I don't recall whether I retested after
the (incomplete)
On Mon, Jan 26, 2015 at 01:11:01PM +0100, Richard Biener wrote:
I agree that freeing the cfg and immediately computing it again doesn't make
sense, but I just don't see this patch being incompatible with that.
I wonder if handing over pass pipeline control to targets at
machine_reorg time
On 20 January 2015 at 15:34, Christophe Lyon christophe.l...@linaro.org wrote:
On 16 January 2015 at 19:29, Tejas Belagod tejas.bela...@arm.com wrote:
+VECT_VAR_DECL(expected,poly,8,16) [] = { 0x33, 0x33, 0x33, 0x33,
+0x33, 0x33, 0x33, 0x33,
+
On 20 January 2015 at 14:57, Renlin Li renlin...@arm.com wrote:
gcc/ChangeLog:
2015-01-20 Renlin Li renlin...@arm.com
* config/aarch64/aarch64.c (aarch64_load_symref_appropriately): Correct
the comment.
* config/aarch64/aarch64.md (tlsle_small_mode): Add left shift 12-bit
On 26 Jan 2015, at 14:13, Rainer Orth wrote:
FX fxcoud...@gmail.com writes:
The default BOOT_CFLAGS are: -O2 -g -mdynamic-no-pic
the libiberty pic build appends: -fno-common (and not even -fPIC) [NB
-fPIC _won't_ override -mdynamic-no-pic, so that's not a simple way out]
This means that
H.J. Lu hjl.to...@gmail.com writes:
On Fri, Jan 16, 2015 at 5:38 AM, Rainer Orth
r...@cebitec.uni-bielefeld.de wrote:
Jakub Jelinek ja...@redhat.com writes:
@@ -311,7 +312,8 @@ proc run-many-tests { testcases extra_fl
set targetabis { }
if [string match $compiler_vendor gnu] {
Uros Bizjak ubiz...@gmail.com writes:
Yes, the name is better. It would also fit with Solaris.
Bootstrap and regression test was OK.
Committed with following ChangeLogs:
libgcc/ChangeLog:
2015-01-23 Uros Bizjak ubiz...@gmail.com
* config/i386/elf-lib.h: New file.
On 26 January 2015 at 13:10, Tejas Belagod tejas.bela...@arm.com wrote:
On 25/01/15 21:05, Christophe Lyon wrote:
On 23 January 2015 at 14:44, Christophe Lyon christophe.l...@linaro.org
wrote:
On 23 January 2015 at 12:42, Christophe Lyon christophe.l...@linaro.org
wrote:
On 23 January
On 20 January 2015 at 15:24, Christophe Lyon christophe.l...@linaro.org wrote:
Here is an updated version, where I have removed a few more useless
variables than you noticed: the [u]int64x1 as well as the 128 bits
ones.
OK /Marcus
Hi!
In r220110, I have committed a merge from trunk r219681 (2015-01-15) into
gomp-4_0-branch. This is the last trunk revision before the »Merge
current set of OpenACC changes from gomp-4_0-branch« commit.
Grüße,
Thomas
pgpFT6G9VIhcG.pgp
Description: PGP signature
On 20 January 2015 at 15:35, Christophe Lyon christophe.l...@linaro.org wrote:
Hmm changed my mind: vpaddl takes only one vector as input, although
it does add 2 vector elements.
Here is an updated version, removing poly, float and int8 variants.
OK /Marcus
-Original Message-
From: Andrew Pinski [mailto:pins...@gmail.com]
Sent: Monday, January 26, 2015 6:03 PM
To: Hale Wang
Cc: GCC Patches
Subject: Re: [PATCH] [gcc, combine] PR46164: Don't combine the insns if a
volatile register is contained.
I think it is allowed to the second
Matthias Klose wrote:
However for the libbacktrace and the libsanitizer builds, the
AM_ENABLE_MULTILIB
macro is included way too late. Scan the generated configure file for
cross_compiling and see that the above snippet is added after the failing
checks. The fix seems to be simple,
Here we do have a hard register, but it isn't valid to form the subreg
on that hard register. Reload had to cope with that case too.
Since the subreg on the original hard register is invalid, we can't use
it to decide whether the intention was to write to only a part of the
inner
On 20 January 2015 at 15:33, Christophe Lyon christophe.l...@linaro.org wrote:
On 16 January 2015 at 19:27, Tejas Belagod tejas.bela...@arm.com wrote:
+VECT_VAR_DECL(expected,poly,16,8) [] = { 0x, 0x, 0x, 0x,
+0x, 0x, 0x,
On 20 January 2015 at 15:32, Christophe Lyon christophe.l...@linaro.org wrote:
No poly or float for vmovl.
Here is a new version, with more cleanup: only 16x8, 32x4 and 64x2
variants are necessary.
This version is OK /Marcus
On Mon, 26 Jan 2015, Jakub Jelinek wrote:
On Mon, Jan 26, 2015 at 04:06:11PM +0100, Richard Biener wrote:
This is the 2nd thing I came up with after looking at PR64277.
VRP does a poor job computing value-ranges of unrolled loop IVs
thus a very simple thing to do is to factor in
On Mon, Jan 26, 2015 at 04:28:02PM +0100, Richard Biener wrote:
Sure - but for unrolling
int a[2];
for (int i = 0; i 5; i++)
a[i] = i;
I'd like to see warnings and we only warn if we unroll this because
the value-range of i includes indexes that are valid.
Don't we warn here for
I've looked at PR64277 and noticed we haven't been applying TLC to the
array-bound warning code for a long time. I noticed we don't
warn for out-of-bound return a[11]; - fixed with the simplifications.
I also noticed that anti-range handling has off-by-one errors
(well, always applied
On Mon, Jan 26, 2015 at 03:57:20PM +0100, Richard Biener wrote:
I've looked at PR64277 and noticed we haven't been applying TLC to the
array-bound warning code for a long time. I noticed we don't
warn for out-of-bound return a[11]; - fixed with the simplifications.
I also noticed that
-Original Message-
From: Robert Suchanek [mailto:robert.sucha...@imgtec.com]
Sent: Monday, January 26, 2015 6:48 AM
To: gcc-patches@gcc.gnu.org
Cc: Matthew Fortune; Moore, Catherine
Subject: [PATCH MIPS RFA] Regression cleanup for nan2008 toolchain
Hi,
Here is a patch to
Hi,
I'm trying to lift the restriction to run auto-vectorization tests
more than once and would like to check if I'm going in the right
direction. I attached a draft patch.
Currently, auto-vectorization tests are enabled by a call to
check_vect_support_and_set_flags procedure and if there is
On Mon, 26 Jan 2015, Jakub Jelinek wrote:
On Mon, Jan 26, 2015 at 04:18:32PM +0100, Richard Biener wrote:
Ok for trunk? Or should I delay this to GCC 6?
Does this work even without the other patch?
Yes, I've actually developed 2/2 first. The other patch only ever
emits more
This is the 2nd thing I came up with after looking at PR64277.
VRP does a poor job computing value-ranges of unrolled loop IVs
thus a very simple thing to do is to factor in previous VRP results
by intersecting what VRP2 computes with recorded SSA name range infos
(that also makes errors in those
2015-01-24 18:18 GMT+01:00 Tobias Burnus bur...@net-b.de:
this is a second patch dealing with finalization-related regressions,
[...]
This patch fixes an invalid memory reference inside the finalizer
routine (at runtime), which apparently was caused by dereferencing a
pointer without checking
This is a minimal backport of features added to GCC 5 to enable use
of binutils 2.25 with GCC 4.9 for MIPS soft-float builds. Further
details in the PR:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64569
The commits which are being backported are listed below (the last
one is posted but
On Mon, Jan 26, 2015 at 04:06:11PM +0100, Richard Biener wrote:
This is the 2nd thing I came up with after looking at PR64277.
VRP does a poor job computing value-ranges of unrolled loop IVs
thus a very simple thing to do is to factor in previous VRP results
by intersecting what VRP2
On Mon, Jan 26, 2015 at 04:18:32PM +0100, Richard Biener wrote:
Ok for trunk? Or should I delay this to GCC 6?
Does this work even without the other patch?
Yes, I've actually developed 2/2 first. The other patch only ever
emits more warnings...
Then it probably should be ok. I'm
There are still bugs in these patches, they should not go in. Hope to have
something ready, with tests, in the next stage 1.
Cheers, Alan
Alan Lawrence wrote:
These add all the V[48]HFmode insns and corresponding intrinsics for ARM.
Depends on the two patches at
On Mon, Jan 26, 2015 at 4:46 AM, Jakub Jelinek ja...@redhat.com wrote:
On Sat, Jan 17, 2015 at 09:18:14PM -0500, David Edelsohn wrote:
Thanks, David
* config/rs6000/default64.h: Include rs6000-cpus.def.
(TARGET_DEFAULT) [LITTLE_ENDIAN]: Use ISA 2.7 (POWER8).
*
On Mon, Jan 26, 2015 at 05:55:52PM +0800, Hale Wang wrote:
The GCC combine pass combines the insns even though they contain volatile
registers.
Local register variable, register asm.
This doesn't make sence.
On the contrary, it makes a lot of sense: you *want* insns 41+43 to be
combined in
On Mon, 26 Jan 2015, Gerald Pfeifer wrote:
On Saturday 2015-01-03 17:59, Sandra Loosemore wrote:
* most places in the manual use null or more rarely @code{NULL}
rather than NULL
So, should this be documented in gcc.gnu.org/codingconventions.html?
Expanding / revising where it says NULL
On Mon, Jan 26, 2015 at 11:08 AM, Allan Sandfeld Jensen
carew...@gmail.com wrote:
On Monday 26 January 2015, H.J. Lu wrote:
On Mon, Jan 26, 2015 at 10:53 AM, Allan Sandfeld Jensen
carew...@gmail.com wrote:
Committed with a bunch of fixes (e.g. missing fold_builtin_cpu
part in
On Monday 26 January 2015, H.J. Lu wrote:
On Mon, Jan 26, 2015 at 11:08 AM, Allan Sandfeld Jensen
carew...@gmail.com wrote:
On Monday 26 January 2015, H.J. Lu wrote:
On Mon, Jan 26, 2015 at 10:53 AM, Allan Sandfeld Jensen
carew...@gmail.com wrote:
Committed with a bunch of fixes
Jason, Joseph, this is stage 1 material (unless someone else wants to try and
make an argument for it sooner), if you could review the parser (frontend)
bits, that would be wonderful. The mid-end, and back-end bits Richard was
reviewing.
On Jan 8, 2015, at 4:45 AM, Richard Biener
On 20 January 2015 at 15:30, Christophe Lyon christophe.l...@linaro.org wrote:
+ /* Apply a unary operator named INSN_NAME. */
Unary op?
Hmm cut paste issue. Thanks
Here is an updated versoin, also renaming VPADD into VPXXX, since it's
in a template.
Updated version is OK /Marcus
On 26 Jan 14:44, Thomas Schwinge wrote:
On 17 Jan 02:16, Ilya Verbin wrote:
Such things are not covered by the
testsuite, that's why you missed this issue. Here is a simple testcase:
http://news.gmane.org/find-root.php?message_id=%3C20150116231632.GB48380%40msticlxl57.ims.intel.com%3E
The following fixes PR64764.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2015-01-26 Richard Biener rguent...@suse.de
PR middle-end/64764
* tree-ssa-uninit.c (is_pred_expr_subset_of): Handle
combining two BIT_AND_EXPR predicates.
On Mon, Jan 26, 2015 at 10:53 AM, Allan Sandfeld Jensen
carew...@gmail.com wrote:
Committed with a bunch of fixes (e.g. missing fold_builtin_cpu part
in gcc/config/i386/i386.c, and mv17.C test didn't compile at all due
to missing parenthesis).
... and now with committed ChangeLog
On Mon, Jan 26, 2015 at 8:15 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Mon, Jan 26, 2015 at 11:08 AM, Allan Sandfeld Jensen
carew...@gmail.com wrote:
On Monday 26 January 2015, H.J. Lu wrote:
On Mon, Jan 26, 2015 at 10:53 AM, Allan Sandfeld Jensen
carew...@gmail.com wrote:
Committed with
On 01/24/15 04:29, Richard Sandiford wrote:
Yeah. I expect in practice most people who used ? and ! attached
them to a particular operand for a reason. From a quick scan through
386.exp it looked like almost all uses would either want this behaviour
or wouldn't care. An interesting exception
On Monday 26 January 2015, you wrote:
On Mon, Jan 26, 2015 at 10:38 AM, Allan Sandfeld Jensen
al...@carewolf.com wrote:
On Monday 26 January 2015, H.J. Lu wrote:
On Sun, Jan 25, 2015 at 10:37 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Sun, Jan 25, 2015 at 7:23 PM, Uros Bizjak
On Monday 26 January 2015, H.J. Lu wrote:
On Mon, Jan 26, 2015 at 10:53 AM, Allan Sandfeld Jensen
carew...@gmail.com wrote:
Committed with a bunch of fixes (e.g. missing fold_builtin_cpu
part in gcc/config/i386/i386.c, and mv17.C test didn't compile at
all due to missing
Hello!
Attached patch tightens the condition for TYPE_LEA instructions.
2015-01-26 Uros Bizjak ubiz...@gmail.com
PR target/64795
* config/i386/i386.md (*movdi_internal): Also check operand 0
to determine TYPE_LEA operand.
(*movsi_internal): Ditto.
Bootstrapped and
On Mon, Jan 26, 2015 at 8:22 PM, Allan Sandfeld Jensen
carew...@gmail.com wrote:
I guess since they represent the exact same effective ISA, they would
have equal priority, so that it would likely chose whatever comes last.
I have no strong opinion on this. But this is a user visible
I missed including the documentation patch in the last set. :-( Here it is:
Index: extend.texi
===
--- extend.texi (revision 220084)
+++ extend.texi (working copy)
@@ -17881,6 +17881,17 @@ void ignore_vec_dep (int *a, int k, int
On Mon, Jan 26, 2015 at 05:55:52PM +0800, Hale Wang wrote:
diff --git a/gcc/combine.c b/gcc/combine.c
index 5c763b4..cf48666 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -2004,6 +2004,13 @@ can_combine_p (rtx_insn *insn, rtx_insn *i3, rtx_insn
*pred ATTRIBUTE_UNUSED,
return
---On Mon, Jan 26, 2015 at 11:25 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Mon, Jan 26, 2015 at 8:22 PM, Allan Sandfeld Jensen
carew...@gmail.com wrote:
I guess since they represent the exact same effective ISA, they would
have equal priority, so that it would likely chose whatever comes
On Monday 26 January 2015, H.J. Lu wrote:
On Sun, Jan 25, 2015 at 10:37 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Sun, Jan 25, 2015 at 7:23 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Sat, Jan 24, 2015 at 11:49 AM, Allan Sandfeld Jensen
al...@carewolf.com wrote:
On Saturday 24
On Mon, Jan 26, 2015 at 10:04 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Sun, Jan 25, 2015 at 10:37 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Sun, Jan 25, 2015 at 7:23 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Sat, Jan 24, 2015 at 11:49 AM, Allan Sandfeld Jensen
al...@carewolf.com wrote:
Hi,
Currently chkp_call_returns_bounds_p works incorrectly for bounds narrowing.
Also it doesn't reflect recent changes in calls instrumentation. This patch
fixes the problem.
Bootstrapped and checked on x86_64-unknown-linux-gnu. OK for trunk?
Thanks,
Ilya
--
2015-01-26 Ilya Enkovich
Hi DJ,
The attached patch provides some enhancements to libgcc for the RL78.
It includes faster and smaller versions of the bit counting and simple
floating point functions, and a version of the integer multiply
support function designed to work on the G10.
Tested on an rl78-elf
On 01/26/2015 06:19 AM, Rainer Orth wrote:
2015-01-16 Rainer Orth r...@cebitec.uni-bielefeld.de
* testsuite/lib/libffi.exp: Load target-supports.exp.
(run-many-tests): Only set targetabis for ia32.
Ok.
r~
On Mon, Jan 26, 2015 at 10:38 AM, Allan Sandfeld Jensen
al...@carewolf.com wrote:
On Monday 26 January 2015, H.J. Lu wrote:
On Sun, Jan 25, 2015 at 10:37 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Sun, Jan 25, 2015 at 7:23 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Sat, Jan 24, 2015 at
On Mon, 2015-01-26 at 12:43 +0100, Gerald Pfeifer wrote:
On Friday 2015-01-23 17:44, David Malcolm wrote:
The following patch builds and installs the JIT documentation for
the website (just HTML for now).
It's tricky to test (I don't have a copy of /www/gcc/bin/preprocess),
but I was
Hello,
The LEGITIMIZE_RELOAD_ADDRESS macro is only needed for reload. Since the
Aarch64 backend no longer supports reload, this macro is not needed and
this patch removes it.
Tested aarch64-none-linux-gnu with gcc-check. No new failures.
Ok for trunk?
Matthew
gcc/
2015-01-26 Matthew Wahab
Hi DJ,
The patch below contains two minor enhancements for the RL78 prologue
and epilogue code. The first is for when a large amount of local
stack space needs to be allocated. Rather than generating a long
sequence of SUB SP, #byte instructions, the patched codes moves SP
into AX,
On Sun, Jan 25, 2015 at 10:37 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Sun, Jan 25, 2015 at 7:23 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Sat, Jan 24, 2015 at 11:49 AM, Allan Sandfeld Jensen
al...@carewolf.com wrote:
On Saturday 24 January 2015, Uros Bizjak wrote:
On Mon, Jan 12, 2015
The test case listed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46164
shows the expected asm command mov r1, r1 is not generated.r1 is defined
as a volatile register, and there are three insns related to r1:
(insn 98 97 40 3 (set (reg/v:SI 1 r1 [ b ]) (reg:SI 154 [ b ]))
On Jan 26, 2015, at 3:43 AM, Gerald Pfeifer ger...@pfeifer.com wrote:
+# Again, the jit is a special case, with nested subdirectories
+# below jit, and with some non-HTML files (.png images from us,
+# plus .js and .css supplied by sphinx).
+for file in $(find jit \
+-name
On 01/26/15 06:34, Jakub Jelinek wrote:
On Mon, Jan 26, 2015 at 01:11:01PM +0100, Richard Biener wrote:
I agree that freeing the cfg and immediately computing it again doesn't make
sense, but I just don't see this patch being incompatible with that.
I wonder if handing over pass pipeline
Hi!
On various targets, %s in fprintf can't handle NULL arguments,
and even when edge-call_stmt is non-NULL, it still might have
UNKNOWN_LOCATION or BUILTINS_LOCATION, which have NULL filename.
In this particular case it is a fnsplit created call.
Fixed thusly, bootstrapped/regtested on
Hi Janus,
The testcase has a dependence on libubsan.so, which my LD_LIBRARY_PATH
does not seem to be able to resolve. It therefore fails in the
regression test. When I point to ~/lib64, I get the message:
/svn/trunk/gcc/testsuite/gfortran.dg/class_allocate_18.f90:8: runtime
error: signed integer
Hi!
On x86_64-darwin, we ICE on one of the pr64307.c testcase, because
expand_thunk doesn't load non-gimple_val arguments into registers
for the first argument, only for all the other ones.
Supposedly normally thunks were meant to have this argument as pointer first
and thus it wasn't an issue,
Hi!
On the following testcase we generate wrong code, because
apparently divmod_internal_2 relies on 0 being the topmost
element (at b_dividend[m]):
algorithm. M is the number of significant elements of U however
there needs to be at least one extra element of B_DIVIDEND
allocated, N is
Hi!
If #pragma omp declare simd function has a name set using __asm,
DECL_ASSEMBLER_NAME starts with *. We certainly don't want to put
that * as part of the mangled name, if not anything else because
most of the assemblers don't handle it as part of identifiers.
Fixed thusly, committed to trunk
On 01/26/15 09:45, Ilya Enkovich wrote:
Hi,
Currently chkp_call_returns_bounds_p works incorrectly for bounds narrowing.
Also it doesn't reflect recent changes in calls instrumentation. This patch
fixes the problem.
Bootstrapped and checked on x86_64-unknown-linux-gnu. OK for trunk?
Dear All,
The fix for the failing testcases in comments #6 and #7 in this PR
have been fixed as 'obvious' in r220140.
Thanks to Mikael for reopening the PR as a placeholder.
This is such an embarrassing bug that I intend to commit to 4.9 as
well even if it is not a regression, unless there are
On Mon, Jan 26, 2015 at 10:10:56PM +0100, Jakub Jelinek wrote:
Hi!
On the following testcase we ICE, because we end up with a CALL_EXPR
with error_mark_node argument and gimplification can't cope with that.
Normally, if one or more arguments are error_mark_node we return -1
and drop the
Hi!
On various targets, %s in fprintf can't handle NULL arguments,
and even when edge-call_stmt is non-NULL, it still might have
UNKNOWN_LOCATION or BUILTINS_LOCATION, which have NULL filename.
In this particular case it is a fnsplit created call.
Fixed thusly, bootstrapped/regtested on
libgccjit.so is installed by jit/Make-lang.in's jit.install-common,
into $(DESTDIR)/$(libdir).
jit/config-lang.in listed compilers as libgccjit.so, leading
to the makefile variable COMPILERS containing libgccjit.so. This in
turn led to gcc/Makefile's install-common installing a redundant
copy of
Hi!
On the following testcase we ICE during error recovery.
Setting DECL_INITIAL of a FUNCTION_DECL to error_mark_node can't
be possibly helpful, the error must have been diagnosed already;
DECL_INITIAL on the FUNCTION_DECL should be kept as BLOCK.
Bootstrapped/regtested on x86_64-linux and
On 01/22/15 13:50, Chen Gang S wrote:
On 01/23/2015 03:53 AM, Jeff Law wrote:
On 01/22/15 12:42, Chen Gang S wrote:
Thank you very much for your help applying the 3 patches. :-)
No problem.
After finish the assignment working flow, I guess, I may have the write
access, then can finish
On 01/26/15 14:13, Jakub Jelinek wrote:
Hi!
On the following testcase we ICE during error recovery.
Setting DECL_INITIAL of a FUNCTION_DECL to error_mark_node can't
be possibly helpful, the error must have been diagnosed already;
DECL_INITIAL on the FUNCTION_DECL should be kept as BLOCK.
On 01/26/15 07:30, Tobias Burnus wrote:
Matthias Klose wrote:
However for the libbacktrace and the libsanitizer builds, the AM_ENABLE_MULTILIB
macro is included way too late. Scan the generated configure file for
cross_compiling and see that the above snippet is added after the failing
checks.
Gerald,
Could I get a hand on checking in this last addition?
-m 'Add a blurb to htdocs/gcc-5/changes.html to explain the
__has_cpp_attribute and
the equivalent __has_attribute macros.'
Thanks,
Ed
Sorry, I forgot to add gcc-patches.
Index: htdocs/gcc-5/changes.html
+/* Workaround -Wstrict-overflow false positive during profiledbootstrap. */
+
+# if GCC_VERSION = 4004
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored -Wstrict-overflow
+#endif
+
#pragma diagnostic ignored was added in 4.4 but #pragma diagnostic
push/pop wasn't added until
Ping?
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
Sent: Friday, January 23, 2015 4:23 PM
To: Ramana Radhakrishnan
Cc: gcc-patches
Subject: RE: [PATCH, ARM] Fix PR64453: live high register not saved
-Original Message-
From: Segher Boessenkool [mailto:seg...@kernel.crashing.org]
Sent: Tuesday, January 27, 2015 3:07 AM
To: Hale Wang
Cc: GCC Patches
Subject: Re: [PATCH] [gcc, combine] PR46164: Don't combine the insns if a
volatile register is contained.
On Mon, Jan 26, 2015 at
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
Secondly, in a shared library environment you need to ensure that
these
names remain private to the instance linked into the library, so that
you don't end up going through the
Hi all,
As described in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64741 ,
ASan may currently report false positives for UBSan internal variables
due to their incomplete type information. This patch fixes this.
Bootstrapped and regtested on Linux x64. Ok to commit?
-Y
commit
Segher: I know you're not officially noted as a maintainer or reviewer
for combine.c, but that's something I'd like to change if you're
interested in a larger role. In the mean time, any feedback you have
would be appreciated.
So the issue mentioned in the BZ is that fairly obvious code
On Mon, Jan 26, 2015 at 08:07:29PM -0700, Jeff Law wrote:
The second change we need is an additional simplification.
If we have
(subreg:M1 (zero_extend:M2 (x))
Where M1 M2 and both are scalar integer modes. It's advantageous to
strip the SUBREG and instead have a wider extension.
-Original Message-
From: Segher Boessenkool [mailto:seg...@kernel.crashing.org]
Sent: Tuesday, January 27, 2015 12:52 PM
To: Hale Wang
Cc: GCC Patches
Subject: Re: [PATCH] [gcc, combine] PR46164: Don't combine the insns if a
volatile register is contained.
On Tue, Jan 27, 2015
On Tue, Jan 27, 2015 at 11:49:55AM +0800, Hale Wang wrote:
Hi Hale,
diff --git a/gcc/testsuite/gcc.target/arm/pr46164.c
b/gcc/testsuite/gcc.target/arm/pr46164.c
new file mode 100644
index 000..ad3b7cb
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/pr46164.c
@@ -0,0
From: Richard Earnshaw
Sent: Wednesday, January 14, 2015 10:49 PM
Sorry, not ok. These symbols pollute the global namespace, yet do not
use reserved names.
Are you referring to the Lml_* symbols? They appear with local binding in
my environment which is expected since the single float and
On 01/20/2015 12:02 PM, H.J. Lu wrote:
On Tue, Jan 20, 2015 at 10:51 AM, Eric Botcazou ebotca...@adacore.com wrote:
Ping? Any thoughts?
x86 for the family and x86-32/x86-64 for the 2 architectures?
Works for me.
[redirecting from gcc@ to gcc-patches@]
OK, here is a patch that attempts
Dear Janus,
I know somewhat less than nothing about such matters. I suggest that
you contact the authors of the testcases that use libubsan that you
mention.
Sorry
Paul
On 26 January 2015 at 22:20, Janus Weil ja...@gcc.gnu.org wrote:
Hi Paul,
The testcase has a dependence on libubsan.so,
Updated patch below.
Jakub Jelinek wrote:
On Mon, Jan 26, 2015 at 01:14:39PM +0100, Tobias Burnus wrote:
The question is why I didn't see the nonsense in the test suite. It
doesn't seem to be tested for in gcc/testsuite/gfortran.dg/; it might be
tested in libgomp/testsuite/ - I don't recall
This patch is to fix 2 issues found in dbr_schedule when trying to
fix PR target/64761. The first is relax_delay_slots removes
the jump insn in the insns like below:
(jump_insn/j 74 58 59 (set (pc) (label_ref:SI 29)) ...)
(barrier 59 74 105)
(note 105 59 29 NOTE_INSN_SWITCH_TEXT_SECTIONS)
[i'd like to add Joern to CC list because this is based on his patch.]
Hi,
This patch series is to fix PR target/64761 which is formally a 4.9/5
regression. The fix is splitted into 3 pieces:
[PATCH 1/3] Replace MD_REDIRECT_BRANCH with TARGET_CAN_FOLLOW_JUMP
[PATCH 2/3] [SH] Add jump insn for
This patch adds a new jump insn for the jump crossing between hot/cold
pertitions and reenables -freorder-blocks-and-partition on SH in
some cases.
--
PR target/64761
* config/sh/sh.c (sh_option_override): Don't change
-freorder-blocks-and-partition to -freorder-blocks
On Thu, 2015-01-22 at 23:46 +0100, Oleg Endo wrote:
I will install this the patch from
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01743.html
in 24h if there are no further objections.
The above mentioned patch has been committed as r220081. This is a
small follow up patch that fixes two
gcc_jit_context_get_last_error was documented as returning a string that's
valid for the rest of the lifetime of the context. In fact, the buffer
becomes invalid if any other errors occur on the context.
Fix the docs and header file comments to reflect this.
Also, fix a couple of other minor jit
See $subj. Committed.
* config/rl78/rl78.c (move_elim_pass): Don't optimize away
volatile memory references.
Index: config/rl78/rl78.c
===
--- config/rl78/rl78.c (revision 220150)
+++ config/rl78/rl78.c (working
On Sat, Jan 17, 2015 at 09:18:14PM -0500, David Edelsohn wrote:
Thanks, David
* config/rs6000/default64.h: Include rs6000-cpus.def.
(TARGET_DEFAULT) [LITTLE_ENDIAN]: Use ISA 2.7 (POWER8).
* config/rs6000/driver-rs6000.c (detect_processor_aix): Add POWER7.
*
It's an uninitialized variable in a testcase I added back in 2008 that had
been silent until we started to generate overflow checks by default.
Tested on x86_64-suse-linux, applied on the mainline and 4.9 branch.
2015-01-26 Eric Botcazou ebotca...@adacore.com
PR testsuite/64712
1 - 100 of 144 matches
Mail list logo
