Hi!
I'd like to ping a few unreviewed patches:
- use libbacktrace in libsanitizer symbolization - PR sanitizer/59136
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00558.html
- allow building libsanitizer against older kernel headers
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00963.html
-
Bernd Edlinger bernd.edlin...@hotmail.de writes:
Hello,
on i686-pc-linux-gnu the test case gcc.target/i386/intrinsics_4.c fails
because of
an internal compiler error, see PR58155.
The reason for this is that the optab CODE_FOR_movv8sf is disabled when it
should be enabled.
This happens
Dear Janus, dear all,
Happy New Year!
The patch is OK for trunk.
Thanks a lot.
Paul
On 3 January 2014 10:29, Janus Weil ja...@gcc.gnu.org wrote:
In addition this patch fixes PR 59662.
Also: Ping!
Cheers,
Janus
2013/12/31 Janus Weil ja...@gcc.gnu.org:
Hi all,
... and the
On Mon, Jan 06, 2014 at 10:27:06AM +, Richard Sandiford wrote:
Of course, IMO, the cleanest fix would be to use switchable targets
for i386...
We IMHO want that anyway, e.g. #pragma omp declare simd tests take eons to
compile because even with just a few routines in a CU there are hundreds
This is the ICE on the checking assertion for ONEPART_VALUEs at the beginning
of vt_expand_var_loc_chain. The assertion looks a bit overzealous to me: it
triggers here because we don't record a SET in add_stores, but only because we
don't preserve the source: the source is a zero-extension of
On Fri, Jan 03, 2014 at 05:17:28PM +, Joseph S. Myers wrote:
Implementation-defined behavior is documented in implement-c.texi, so this
patch is incomplete as it doesn't update that file where it says:
No other types are permitted in strictly conforming mode.
@c Would it be
Hi,
This patch fixes vector shift by 64 behavior to meet reference
manual expectations. Testcase included to check that expectations
are now met. No regressions found.
Is patch OK?
Thanks,
Alex
2014-01-06 Alex Velenko alex.vele...@arm.com
gcc/
*
Jakub Jelinek ja...@redhat.com wrote:
On Mon, Jan 06, 2014 at 10:27:06AM +, Richard Sandiford wrote:
Of course, IMO, the cleanest fix would be to use switchable targets
for i386...
We IMHO want that anyway, e.g. #pragma omp declare simd tests take eons
to
compile because even with just a
This patch fixes the implementation of vcvtmd_s64_f64 and vcvtpd_s64_f64
in arm_neon.h to use llfloor and llceil instead, which are ILP32-friendly.
This patch will fix the following test failure in the ILP32 mode:
FAIL: gcc.target/aarch64/vect-vcvt.c scan-assembler fcvtms\\tx[0-9]+,
d[0-9]+
The new Declare fma in gcc.target/i386/pr59390*.c tests were FAILing on
Solaris 9/x86, which lacks C99 support:
FAIL: gcc.target/i386/pr59390.c (test for excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/pr59390.c:12:9: warnin
g: implicit declaration of
The new gcc.target/i386/pr59501-*.c tests were FAILing on Solaris 9/x86
with Sun as:
FAIL: gcc.target/i386/pr59501-1.c (test for excess errors)
Excess errors:
Assembler: pr59501-1.c
/var/tmp//cclOtnd2.s, line 28 : Illegal mnemonic
/var/tmp//cclOtnd2.s, line 28 : Syntax error
and
Several of the new AVX512F tests were FAILing on Solaris 10+/x86:
FAIL: gcc.target/i386/avx512f-vcmppd-2.c (test for excess errors)
WARNING: gcc.target/i386/avx512f-vcmppd-2.c compilation failed to produce
executable
Excess errors:
Undefined first referenced
symbol
Hello!
2014-01-03 Rainer Orth r...@cebitec.uni-bielefeld.de
* gcc.target/i386/pr59501-1.c: Require avx effective target.
* gcc.target/i386/pr59501-2.c: Likewise.
* gcc.target/i386/pr59501-3.c: Likewise.
* gcc.target/i386/pr59501-4.c: Likewise.
* gcc.target/i386/pr59501-5.c: Likewise.
*
Hello!
2014-01-06 Rainer Orth r...@cebitec.uni-bielefeld.de
* gcc.target/i386/pr59390.c: Replace math.h by fma declaration.
* gcc.target/i386/pr59390_1.c: Likewise.
* gcc.target/i386/pr59390_2.c: Likewise.
OK.
Thanks,
Uros.
The new gcc.dg/vect/vect-simd-clone-*.c tests were FAILing on Solaris
10+/x86 with Sun as:
FAIL: gcc.dg/vect/vect-simd-clone-1.c execution test
ld.so.1: vect-simd-clone-1.exe: fatal: vect-simd-clone-1.exe: hardware
capability (CA_SUNW_HW_2) unsupported: 0x40 [ 0x40 ]
As can be seen in
Hello!
2014-01-03 Rainer Orth r...@cebitec.uni-bielefeld.de
* gcc.target/i386/avx512f-vcmppd-2.c: Add -std=c99.
Require c99_runtime.
* gcc.target/i386/avx512f-vcmpps-2.c: Likewise.
* gcc.target/i386/avx512f-vfixupimmpd-2.c: Add -std=gnu99.
Require c99_runtime.
*
Hi,
the patch below makes param_index in ipcp_discover_new_direct_edges an
integer. Now it is bool which makes kind of difficult to work with
parameters with index 2 or higher, as demonstrated by the testcase.
Bootstrapped and tested on x86_64-linux, approved by Honza in person,
I am about to
Hi Uros,
2014-01-03 Rainer Orth r...@cebitec.uni-bielefeld.de
* gcc.target/i386/pr59501-1.c: Require avx effective target.
* gcc.target/i386/pr59501-2.c: Likewise.
* gcc.target/i386/pr59501-3.c: Likewise.
* gcc.target/i386/pr59501-4.c: Likewise.
* gcc.target/i386/pr59501-5.c: Likewise.
On Mon, Jan 6, 2014 at 2:53 PM, Rainer Orth r...@cebitec.uni-bielefeld.de
wrote:
2014-01-03 Rainer Orth r...@cebitec.uni-bielefeld.de
* gcc.target/i386/pr59501-1.c: Require avx effective target.
* gcc.target/i386/pr59501-2.c: Likewise.
* gcc.target/i386/pr59501-3.c: Likewise.
*
I was about to open a PR for the same failures on darwin.
Since the tests are supposed to be run, I think they should be skipped
on CPUs not supporting axv instructions. Would not it be better to use
/* { dg-require-effective-target avx_runtime } */
?
Dominique
On Mon, Jan 6, 2014 at 2:57 PM, Dominique Dhumieres domi...@lps.ens.fr wrote:
I was about to open a PR for the same failures on darwin.
Since the tests are supposed to be run, I think they should be skipped
on CPUs not supporting axv instructions. Would not it be better to use
/* {
Since the GCC 4.9.0 release is approaching, we should update the Solaris
baselines again.
This patch does just that, bootstrapped without regressions on the full
rang of Solaris configurations ({i386,sparc}-*-solaris2.{9,10,11}).
Ok for mainline now or better wait until a bit closer to the
On 12/22/2013 01:27 PM, Jan Hubicka wrote:
I believe when the code was created by moving it from elsehwre, the copyright
should say
original date of gcov-io.h.
+
+#include tconfig.h
+#include tsystem.h
+#include coretypes.h
+#include tm.h
+#include libgcc_tm.h
I would really like
On 01/04/2014 04:54 AM, Adam Butcher wrote:
+ /* Declarations involving function parameter lists containing implicit
+ template parameters will have been made into implicit templates. If they
+ do not turn out to be actual function declarations then finish the
+ template
OK.
Jason
On 12/22/2013 01:27 PM, Jan Hubicka wrote:
I believe when the code was created by moving it from elsehwre, the
copyright should say
original date of gcov-io.h.
+
+#include tconfig.h
+#include tsystem.h
+#include coretypes.h
+#include tm.h
+#include libgcc_tm.h
I would really
On 6 January 2014 14:10, Rainer Orth wrote:
Since the GCC 4.9.0 release is approaching, we should update the Solaris
baselines again.
This patch does just that, bootstrapped without regressions on the full
rang of Solaris configurations ({i386,sparc}-*-solaris2.{9,10,11}).
Ok for mainline
I think this is getting too tricky, so let's go back to your first patch
(which is OK). Sorry about the runaround.
Jason
OK.
Jason
On 01/06/2014 09:37 AM, Jan Hubicka wrote:
On 12/22/2013 01:27 PM, Jan Hubicka wrote:
I believe when the code was created by moving it from elsehwre, the copyright
should say
original date of gcov-io.h.
+
+#include tconfig.h
+#include tsystem.h
+#include coretypes.h
+#include tm.h
+#include
Hi!
Ping * 2
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00527.html
Thanks!
OK.
Jason
Hi,
This patch defines the AArch64 BE loader name. Corresponding patches
for glibc and binutils have been posted on the relevant lists.
/Marcus
* config/aarch64/aarch64-linux.h (GLIBC_DYNAMIC_LINKER): Expand
loader
name using mbig-endian.
(LINUX_TARGET_LINK_SPEC):
On Sat, Jan 4, 2014 at 8:16 AM, Joseph S. Myers jos...@codesourcery.com wrote:
This patch fixes various cases of spurious overflow exceptions in the
IBM long double support code. The generic issue is that an initial
approximation is computed by using the relevant arithmetic operation
on the
AArch64 gcc has supported a MADD instruction for a while now.
Unfortunately, it's generally failed to generate it because the costs
returned for it were too high. That's because we cost the operands to
the pattern more than once.
Fixed thusly:
2014-01-06 Richard Earnshaw rearn...@arm.com
On Sat, Jan 04, 2014 at 12:37:57AM +0100, Jakub Jelinek wrote:
That is certainly doable (as attached), but strangely if the patch (that I've
already committed) is reverted and this one applied, the .text savings are
much smaller.
Here are .text and .rodata readelf -WS lines from x86_64
Commit 199570 fixed the --disable-install-libiberty behavior, but it also
added a bug where the enable path never works because the initial clear
of target_header_dir wasn't deleted. So we end up initializing properly
at the top only to reset it at the end all the time.
2014-01-06 Mike
On Mon, 6 Jan 2014, Marek Polacek wrote:
2014-01-06 Marek Polacek pola...@redhat.com
PR c/57773
* doc/implement-c.texi: Mention that other integer types are
permitted as bit-field types in strictly conforming mode.
c/
* c-decl.c (check_bitfield_type_and_width):
Greetings,
For Google b/9127283, I've committed attached patch on google/gcc-4_8 branch.
Related: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56109
This caught ~10 bugs for us. erase(end()) and pop_back() on empty
vector appear to be most common.
--
Paul Pluzhnikov
Index:
On 01/02/14 07:17, Felix Yang wrote:
+2014-01-02 Felix Yangfei.yang0...@gmail.com
+
+* modulo-sched.c (schedule_reg_moves): Clear distance1_uses if it
+is newly allocated.
Thanks. Applied.
If you have a testcase where failure to properly initialize
distance1_uses resulted in some
On 12/27/13 03:16, Jakub Jelinek wrote:
On Fri, Dec 27, 2013 at 02:11:13PM +0400, Andrey Belevantsev wrote:
Testcase is very small. Why not add it?
Frankly, I think that the chances of this test uncovering similar
issues in the future are very small. It needs lots of options to
make it
Jakub Jelinek ja...@redhat.com wrote:
On Mon, Jan 06, 2014 at 10:27:06AM +, Richard Sandiford wrote:
Of course, IMO, the cleanest fix would be to use switchable targets
for i386...
We IMHO want that anyway, e.g. #pragma omp declare simd tests take eons
to
compile because even with just a
On Mon, Jan 6, 2014 at 7:36 AM, Marcus Shawcroft
marcus.shawcr...@arm.com wrote:
Hi,
This patch defines the AArch64 BE loader name. Corresponding patches for
glibc and binutils have been posted on the relevant lists.
This is a huge ABI change and makes GCC 4.8.x incompatible with GCC 4.9.0.
On 01/02/14 19:31, dxq wrote:
hi,
In hw-doloop.c, is there a memory leak?
valgrind checking shows:
==18622== 1,479,296 bytes in 364 blocks are definitely lost in loss record
559 of 559
==18622==at 0x4006ADD: malloc (vg_replace_malloc.c:291)
==18622==by 0x8C0A9D5: xmalloc
On Sun, Jan 5, 2014 at 12:08 PM, Jan Hubicka hubi...@ucw.cz wrote:
2014-01-03 Rong Xu x...@google.com
* gcc/gcov-io.c (gcov_var): Move from gcov-io.h.
(gcov_position): Ditto.
(gcov_is_error): Ditto.
(gcov_rewrite): Ditto.
* gcc/gcov-io.h: Refactor.
On 2014-01-06 14:36, Jason Merrill wrote:
On 01/04/2014 04:54 AM, Adam Butcher wrote:
+ /* Declarations involving function parameter lists containing
implicit
+ template parameters will have been made into implicit
templates. If they
+ do not turn out to be actual function
2014-01-06 Sebastian Huber sebastian.hu...@embedded-brains.de
* config.gcc (*-*-rtems*): Add t-rtems to tmake_file.
(arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*): Do not
override an existing tmake_file.
(arm*-*-rtems*): Use t-rtems from existing tmake_file.
Bernd Edlinger bernd.edlin...@hotmail.de writes:
Jakub Jelinek ja...@redhat.com wrote:
On Mon, Jan 06, 2014 at 10:27:06AM +, Richard Sandiford wrote:
Of course, IMO, the cleanest fix would be to use switchable targets
for i386...
We IMHO want that anyway, e.g. #pragma omp declare simd
This libgo patch from Michael Hudson-Doyle recognizes arm64 as the Go
name for the AArch64 architecture. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 070005ab99f5 libgo/configure.ac
--- a/libgo/configure.ac Sun Jan 05 19:00:53 2014 -0800
+++
I could have sworn I sent this patch out in mid-December, but I don't see it,
so I'm resending this now.
This patch fixes the problem that breaks some code on the SPE. I have patches
for 4.8 and 4.9. Roland says that it fixes the problem in 4.8. In 4.9 there
are other unrelated problems that
Hi Paul,
Happy New Year!
same to you!
The patch is OK for trunk.
Thanks, committed as r206355, reducing the regression count by two in
one go. Unfortunately it's still at what is probably an all-time high
for gfortran (~40).
I'm about to post another regfix soon (for PR 59589), and I'd
Hi!
As discussed in the PR, my recent patch broke the Linux kernel.
The problem is that if register allocation calls ix86_compute_frame_layout
to determine elimination offsets and the DRAP register is assumed saved at
that point, but later on during pro_epilogue pass
On 01/06/2014 01:07 PM, Jakub Jelinek wrote:
2014-01-06 Jakub Jelinek ja...@redhat.com
PR target/59644
* config/i386/i386.h (struct machine_function): Add
no_drap_save_restore field.
* config/i386/i386.c (ix86_save_reg): Use
On 12/19/2013 11:06 AM, Richard Biener wrote:
Aldy Hernandez al...@redhat.com wrote:
I'd still like to catch the common cases, like I do with this patch.
Perhaps we move this code to the .tmmark pass and handle the
uninstrumented case. rth?
tmmark is way way later than you'd want. I
On Mon, 6 Jan 2014 19:16:57, Richard Saniford wrote:
Bernd Edlinger bernd.edlin...@hotmail.de writes:
Jakub Jelinek ja...@redhat.com wrote:
On Mon, Jan 06, 2014 at 10:27:06AM +, Richard Sandiford wrote:
Of course, IMO, the cleanest fix would be to use switchable targets
for i386...
We
Hi all,
here is a regression fix for polymorphic deallocation. The attached
patch is identical in functionality to the one-liner in comment 13 of
the PR, fixing a bug in the detection of finalizable components (with
include allocatable components).
All it does in addition to the one-liner is to
On Mon, Jan 06, 2014 at 11:28:51PM +0100, Janus Weil wrote:
here is a regression fix for polymorphic deallocation. The attached
patch is identical in functionality to the one-liner in comment 13 of
the PR, fixing a bug in the detection of finalizable components (with
include allocatable
On 01/06/14 13:40, Richard Henderson wrote:
On 12/19/2013 11:06 AM, Richard Biener wrote:
Aldy Hernandez al...@redhat.com wrote:
I'd still like to catch the common cases, like I do with this patch.
Perhaps we move this code to the .tmmark pass and handle the
uninstrumented case. rth?
On 01/06/14 15:04, Aldy Hernandez wrote:
On 01/06/14 13:40, Richard Henderson wrote:
On 12/19/2013 11:06 AM, Richard Biener wrote:
Aldy Hernandez al...@redhat.com wrote:
I'd still like to catch the common cases, like I do with this patch.
Perhaps we move this code to the .tmmark pass and
Hi,
The following tiny patch allows GCC to be built with the
--no-builtin-rules GNU make flag. It replaces two usages of the
automatic variable $* within the body of an explicit rule. Using $*
inside the body of an explicit rule should be avoided[0] and, as in
this scenario, may break an
On Mon, Jan 6, 2014 at 6:33 PM, Patrick Palka patr...@parcs.ath.cx wrote:
Hi,
The following tiny patch allows GCC to be built with the
--no-builtin-rules GNU make flag. It replaces two usages of the
automatic variable $* within the body of an explicit rule. Using $*
inside the body of an
Patrick Palka patr...@parcs.ath.cx writes:
From what I inferred from the make manual[0], $* is functionally
equivalent to $(basename $@) in this case.
Or $(base), I think.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276
On Mon, Jan 6, 2014 at 6:47 PM, Andreas Schwab sch...@linux-m68k.org wrote:
Patrick Palka patr...@parcs.ath.cx writes:
From what I inferred from the make manual[0], $* is functionally
equivalent to $(basename $@) in this case.
Or $(base), I think.
Andreas.
--
Andreas Schwab,
On Mon, Jan 6, 2014 at 2:33 PM, Michael Meissner
meiss...@linux.vnet.ibm.com wrote:
I could have sworn I sent this patch out in mid-December, but I don't see it,
so I'm resending this now.
This patch fixes the problem that breaks some code on the SPE. I have patches
for 4.8 and 4.9. Roland
On 01/01/14 16:08, Jakub Jelinek wrote:
On Wed, Jan 01, 2014 at 07:53:48PM +0100, Jakub Jelinek wrote:
Without any gengtype.c changes, I wonder if just following change wouldn't
do it, gengtype considers only char and unsigned char pointers as strings
with the special strlen handling, all other
On 12/31/13 12:04, Jakub Jelinek wrote:
Hi!
As written in the PR, I've been looking why is llvm 3.[34] so much faster
on Scimark2 SOR benchmark and the reason is that it's predictive commoning
or whatever it uses doesn't give up on the inner loop, while our predcom
unnecessarily gives up,
On 12/19/13 13:34, Jakub Jelinek wrote:
On Thu, Dec 19, 2013 at 12:38:49PM +0100, Steven Bosscher wrote:
Why not use active_insn_p instead of hand-checks for USE and CLOBBER insns?
Because it brings in the JUMP_TABLE_DATA mess into the picture?
Not as long as you look only between BB_HEAD
On 01/02/14 10:21, Jan Hubicka wrote:
Hi,
While looking for -Winline messages I noticed that sched-int.h has self
recursive
function declared inline. The recursion is tail recursion but we fail to
recognize
it as such. The problem ist hat there is a local variable link whose address
is passed
On 12/24/13 13:19, Steven Bosscher wrote:
On Fri, Dec 20, 2013 at 7:30 PM, Jeff Law wrote:
So here's an alternate approach to fixing 59285. I still think attacking
this in rtl_merge_blocks is better, but with nobody else chiming in to break
the deadlock Steven and myself are in, I'll go with
I'd prefer to propose another patch that should be commited with this
one, which fix bugs (say _M_flags regex_constants::icase, not ),
and do more matcher optimization.
It is now more DRY (_RegexTranslator) and efficient, but regex
takes longer to compile, mainly because now we have 4 times
70 matches
Mail list logo
