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
takes longer to compile, mainly because now we have 4 times
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 S
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/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 an
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, becaus
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 Mon, Jan 6, 2014 at 2:33 PM, Michael Meissner
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 says that it fixes the
On Mon, Jan 6, 2014 at 6:47 PM, Andreas Schwab wrote:
> Patrick Palka 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 fingerpr
Patrick Palka 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 4ED5
"And now for so
On Mon, Jan 6, 2014 at 6:33 PM, Patrick Palka 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 explicit rule
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 other
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 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
uninstrum
On 01/06/14 13:40, Richard Henderson wrote:
On 12/19/2013 11:06 AM, Richard Biener wrote:
Aldy Hernandez 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 late
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
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 e
On Mon, 6 Jan 2014 19:16:57, Richard Saniford wrote:
>
> Bernd Edlinger writes:
>>>
>>> Jakub Jelinek 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 tha
On 12/19/2013 11:06 AM, Richard Biener wrote:
> Aldy Hernandez 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 believe that
On 01/06/2014 01:07 PM, Jakub Jelinek wrote:
> 2014-01-06 Jakub Jelinek
>
> PR target/59644
> * config/i386/i386.h (struct machine_function): Add
> no_drap_save_restore field.
> * config/i386/i386.c (ix86_save_reg): Use
> !cfun->machine->no_drap_save_restore instea
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
ix86_finalize_stack_realign_fl
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 lo
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 Ro
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
+++
Bernd Edlinger writes:
>>
>> Jakub Jelinek 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
>>
2014-01-06 Sebastian Huber
* 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.
(avr-*-rtems*): Likewise.
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 declaration
On Sun, Jan 5, 2014 at 12:08 PM, Jan Hubicka wrote:
>> 2014-01-03 Rong Xu
>>
>> * 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. Move gcov_var to
On Mon, Jan 6, 2014 at 8:07 AM, Mike Frysinger wrote:
>
> 2014-01-06 Mike Frysinger
>
> PR other/56780
> * configure.ac: Delete target_header_dir assignment.
> * configure: Regenerated.
This is OK.
Thanks.
Ian
Hello,
I will try to produce a testcase for 4.8 and/or that doesn't involve OOP.
I come back to you later.
Thanks for the review.
Mikael
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 (xmalloc.c:14
On Mon, Jan 6, 2014 at 7:36 AM, Marcus Shawcroft
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.
Thanks,
Andrew
>
>
>
> Jakub Jelinek 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 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 trigge
On 01/02/14 07:17, Felix Yang wrote:
+2014-01-02 Felix Yang
+
+* 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 kind of unexpected behavi
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: libstdc++-v3/include/
On Mon, 6 Jan 2014, Marek Polacek wrote:
> 2014-01-06 Marek Polacek
>
> 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): Warn for impl
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 Frysinger
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
* aarch64.c
On Sat, Jan 4, 2014 at 8:16 AM, Joseph S. Myers 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 high parts of the ope
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 (
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): Pas
OK.
Jason
Hi!
Ping * 2
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00527.html
Thanks!
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"
+#in
OK.
Jason
I think this is getting too tricky, so let's go back to your first patch
(which is OK). Sorry about the runaround.
Jason
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 main
> 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 "l
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 declaration
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 li
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 releas
On Mon, Jan 6, 2014 at 2:57 PM, Dominique Dhumieres 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
>
> /* { dg-require-effective-tar
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:53 PM, Rainer Orth
wrote:
>>> 2014-01-03 Rainer Orth
>>>
>>> * 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.t
Hi Uros,
>> 2014-01-03 Rainer Orth
>>
>> * 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.
>> * gcc.target/i
Hello!
> 2014-01-03 Rainer Orth
>
> * 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.
> * gcc.target/i386/avx512f-vfixupimmps-2.c: Lik
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 co
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 , this i
Hello!
> 2014-01-06 Rainer Orth
>
> * 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.
Hello!
> 2014-01-03 Rainer Orth
>
> * 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.
> * gcc.target/i386/pr5950
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
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
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 funct
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]+
Jakub Jelinek 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 few routin
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
gcc/
* config/aarch64/aarch64-simd-builtins.def (ashr): DI mode
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
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 s
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
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 wrote:
> In addition this patch fixes PR 59662.
>
> Also: Ping!
>
> Cheers,
> Janus
>
>
>
> 2013/12/31 Janus Weil :
>> Hi all,
>>
>> ... and the reg-bashing continues: Here
Bernd Edlinger 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 because invoke_se
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
- u
72 matches
Mail list logo
