Hi,
while looking into firefox profiles, I noticed that we miss devirtualizations
to comdat symbols, because we manage to get different profile_id in each
unit. This is easily fixed by the following patch that makes profiled_id
to by crc32 of the symbol name in this case.
Bootstrapped/regtested
Hi,
this one liner should save some WPA streaming memory by throwing out the
inline info that is no longer needed after partitioning.
Bootstrapped/regtested x86_64-linux, tested with Firefox, will commit
it tomorrow.
* lto/lto.c: Include ipa-inline.h
(do_whole_program_analysis):
This patch adds initial set of tests and dg infrastructure for
LeakSanitizer runtime.
Are you sure we need testsuite for something that doesn't have a GCC code
generation counterpart at all?
That's a valid point. We want this in GCC because
(1) support for cross-compilation and cross-testing
Hi,
while looking into -ftime-report, I noticed that ggc can take up to 10% of WPA
memory
while it does almost nothing: it is run just after streaming that explicitly
frees memory that becomes unreachable. The first GGC run usually saves at
most 1% of memory and then it is never run again.
I
Hi,
this patch fixes the last failed fortran test case on arm-linux-gnueabihf:
select_type_4.f90, which did always fail at -O2 and above.
It was caused by a strict aliasing violation, when passing a value of the type
class(x),pointer to a formal procedure parameter of the type
class(x),target.
On Thu, Apr 10, 2014 at 02:18:26PM +0100, Ramana Radhakrishnan wrote:
I see failures from last night on aarch64-none-elf and arm-none-eabi
(both bare-metal) configurations even after moving up to dejagnu
1.5.1. If this can't be fixed easily should we consider reverting this
patch in the
On 04/11/2014 08:00 AM, Jan Hubicka wrote:
Hi,
while looking into firefox profiles, I noticed that we miss devirtualizations
to comdat symbols, because we manage to get different profile_id in each
unit. This is easily fixed by the following patch that makes profiled_id
to by crc32 of the
Hi there,
Current gcc prefers to using two LDR instructions to load 64bit constants.
This could miss some chances that 64bit load can be done in fewer
instructions or fewer cycles. For example, below code to load 0x10001
mov r0, #1
mov r1, #1
is better than current solution:
On Thu, 2014-04-10 at 10:51 -0700, Cary Coutant wrote:
However it would be nice to be assured that the gcc change is ok in
principle first.
The DWARF bits are fine with me.
Thanks. Who can approve the other bits?
When approved should I wait till stage 1 opens before committing?
Thanks,
Hi there,
Could you please review patch at
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00790.html? Thanks.
BR,
Terry
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Terry Guo
Sent: Monday, March 17, 2014 11:36 AM
To:
On Fri, 11 Apr 2014, Jan Hubicka wrote:
Hi,
while looking into -ftime-report, I noticed that ggc can take up to 10% of
WPA memory
while it does almost nothing: it is run just after streaming that explicitly
frees memory that becomes unreachable. The first GGC run usually saves at
most
On Tue, Apr 8, 2014 at 6:55 PM, Teresa Johnson tejohn...@google.com wrote:
This patch removes the printing of details for BBs that are being removed.
When printing bb details, dump_bb_info will invoke check_bb_profile, which
will
flag spurious profile insanities in the removed bb since the
On Thu, Apr 10, 2014 at 10:42 AM, Ramana Radhakrishnan ramra...@arm.com wrote:
4.9 changes for ARM / AArch64. Sorry it's taken me a while to get this out
but better late than never :)
Ok ?
Ok.
Thanks,
Richard.
Ramana
--
Ramana Radhakrishnan
Principal Engineer
ARM Ltd.
Hi Teresa,
@@ -1947,7 +1947,7 @@ remove_bb (basic_block bb)
fprintf (dump_file, Removing basic block %d\n, bb-index);
if (dump_flags TDF_DETAILS)
{
- dump_bb (dump_file, bb, 0, dump_flags);
+ dump_bb (dump_file, bb, 0, dump_flags ~TDF_DETAILS);
On 04/11/2014 08:07 AM, Jan Hubicka wrote:
Hi,
while looking into -ftime-report, I noticed that ggc can take up to 10% of WPA
memory
while it does almost nothing: it is run just after streaming that explicitly
frees memory that becomes unreachable. The first GGC run usually saves at
most 1% of
On Thu, Mar 20, 2014 at 09:48:58AM -0700, Steve Ellcey wrote:
This patch fixes pr60556, a GCC ICE. The problem is in convert_move where,
if we are trying to put a 32 bit address into a 64 bit destination we
can wind up calling emit_move_insn with NULL_RTX as a source.
The problem comes
On 11 April 2014 00:10, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Apr 01, 2014 at 11:41:12AM +0800, Zhenqiang Chen wrote:
Ping?
Bootstrap and no make check regression on X86-64.
Bootstrap on ARM. In ARM regression test, some new PASS and FAIL of
debug info check for
On Fri, Apr 11, 2014 at 05:19:59PM +0800, Zhenqiang Chen wrote:
Or, fix up the insane arm costs for ASM_OPERANDS:
case ASM_OPERANDS:
/* Just a guess. Cost one insn per input. */
*cost = COSTS_N_INSNS (ASM_OPERANDS_INPUT_LENGTH (x));
return true;
I don't think
On Fri, 11 Apr 2014, Jakub Jelinek wrote:
On Thu, Mar 20, 2014 at 09:48:58AM -0700, Steve Ellcey wrote:
This patch fixes pr60556, a GCC ICE. The problem is in convert_move where,
if we are trying to put a 32 bit address into a 64 bit destination we
can wind up calling emit_move_insn with
The following patch fixes the two related ICEs in the PRs by
properly implementing the recursion in graphite_can_represent_scev
to catch all CHRECs and reject remains with CHRECs.
Bootstrap and regtest ongoing on x86_64-unknown-linux-gnu, will
commit shortly if that succeeds.
Richard.
This fixes the endless error reporting for unhandled aliases
by setting TREE_ASM_WRITTEN on the decls we complained about.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress
(sort-of pointless on that target of course).
Richard.
2014-04-11 Richard Biener rguent...@suse.de
Hi,
I've just applied the attached patch to mainline and 4.8 branch.
The patch makes htm target check to also cover the required assembler
support and does some minor cleanup work.
Bye,
-Andreas-
2014-04-11 Andreas Krebbel andreas.kreb...@de.ibm.com
*
Both premature (can't find or think of an existing place that would
rely on those) and bogus, - (4 /[fl] 5) isn't equal to (4 /[fl] -5).
Removing and not trying to fold into 4 /[cl] -5 as we have no good
way of creating testcases (that also include the negation).
Bootstrap / regtest on
Hi Bernd,
Bernd Edlinger wrote:
It was caused by a strict aliasing violation, when passing a value of the type
class(x),pointer to a formal procedure parameter of the type
class(x),target.
I assume a VIEW_CONVERT_EXPR is directly on the argument is insufficient?
Otherwise,
I think I would
On Fri, 11 Apr 2014, Richard Biener wrote:
The following patch fixes the two related ICEs in the PRs by
properly implementing the recursion in graphite_can_represent_scev
to catch all CHRECs and reject remains with CHRECs.
Bootstrap and regtest ongoing on x86_64-unknown-linux-gnu, will
On Sat, Mar 29, 2014 at 10:51:58AM +0100, Tobias Burnus wrote:
2014-03-29 Tobias Burnus bur...@net-b.de
PR other/59055
* doc/bugreport.texi (Bugs): Remove nodes pointing to the
nirvana.
* doc/gcc.texi (Service): Update description in the @menu
*
On Fri, 11 Apr 2014, Richard Biener wrote:
Both premature (can't find or think of an existing place that would
rely on those) and bogus, - (4 /[fl] 5) isn't equal to (4 /[fl] -5).
Removing and not trying to fold into 4 /[cl] -5 as we have no good
way of creating testcases (that also include
Hi,
some time ago I looked a bit into this issue: from the diagnostic point
of view, we can probably do better, but we can safely avoid a couple of
ICEs by simply checking the second argument for error_mark_node and by
using get_attribute_name instead of TREE_PURPOSE for an attribute which
On Fri, Apr 11, 2014 at 01:03:51PM +0200, Richard Biener wrote:
Both premature (can't find or think of an existing place that would
rely on those) and bogus, - (4 /[fl] 5) isn't equal to (4 /[fl] -5).
Removing and not trying to fold into 4 /[cl] -5 as we have no good
way of creating testcases
Hi Tobias,
On Fri, 11 Apr 2014 13:37:46, Tobias Burnus wrote:
Hi Bernd,
Bernd Edlinger wrote:
It was caused by a strict aliasing violation, when passing a value of the
type
class(x),pointer to a formal procedure parameter of the type
class(x),target.
I assume a VIEW_CONVERT_EXPR is
Hi,
Attached are patches to enable gccgo to build properly on Debian
GNU/Hurd on gcc-4.9 (4.9-20140406). With split stack disabled around 70
libgo tests PASS and 50 FAIL (result seems to be somewhat random,
alignment problems there too?). With split stack enabled _all_ tests
fail, see
---BeginMessage---
(continued)
patch4.diff: src/libgo/go/syscall/libcall_posix-1.go:
New file, a copy of libcall_posix.go with the mount call removed.
mount/umount functionality exists but is currently part of Hurd
utilities.
patch5.diff: src/libgo/go/net/sock_gnu.go
Create a dummy function for
---BeginMessage---
(continued)
patch7.diff: src/libgo/go/syscall/wait.c
Set WCONTINUED to zero if not defined (same fix as for lto in gcc-4.9)
patch8.diff: src/libgo/mksysinfo.sh
Add special treatment of EWOULDBLOCK, SYS_FCNTL and st_dev since they
are either not defined or defined differently
Hi Tobias,
On Fri, Apr 11, 2014 at 02:39:57PM +0200, Bernd Edlinger wrote:
On Fri, 11 Apr 2014 13:37:46, Tobias Burnus wrote:
Hmm,
I was hoping somehow that only that test case is broken,
and needs to be fixed. The target attribute is somehow simple,
it implies intent(in) and the actual
Ping~
Originally posted here:
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01282.html
Thanks,
Yufeng
On 03/24/14 17:45, Yufeng Zhang wrote:
Hi,
-free has been enabled by default for -O2 and above on AArch64 a while
ago. This patch updates the relevant part of user manual to reflect the
On Fri, Apr 11, 2014 at 5:47 AM, Svante Signell
svante.sign...@gmail.com wrote:
Attached are patches to enable gccgo to build properly on Debian
GNU/Hurd on gcc-4.9 (4.9-20140406).
Thanks. Will review after 4.9 has branched.
Note: Creating the Makefile.in is hard (unnecessary) work since
On 04/10/2014 10:27 AM, Jakub Jelinek wrote:
I don't see the point of adding the extra {} around the whole case,
there is no variable declared at that point.
Agreed.
+ token = cp_lexer_peek_token (parser-lexer);
+ if (token-type != CPP_SEMICOLON)
+ {
+
Ping?
On Fri, Mar 21, 2014 at 9:16 AM, Paul Pluzhnikov ppluzhni...@google.com wrote:
Greetings,
To fix PR59295, this patch moves (generally useless) warning about
repeated / redundant friend declarations under -Wredundant-decls.
Tested on Linux/x86_64 with no regressions.
Ok for trunk
On Fri, Apr 11, 2014 at 09:20:13AM -0700, Paul Pluzhnikov wrote:
To fix PR59295, this patch moves (generally useless) warning about
repeated / redundant friend declarations under -Wredundant-decls.
Tested on Linux/x86_64 with no regressions.
Ok for trunk once it opens in stage 1?
Although the order of evaluation of function arguments is unspecified,
the order of evaluation of elements of a braced initializer list is
fixed, even if they end up being used as arguments to a constructor;
this was clarified by DR 1030.
This patch handles this by preevaluating affected
+ token = cp_lexer_peek_token (parser-lexer);
+ if (token-type != CPP_SEMICOLON)
+ {
+ error_at (token-location, %_Cilk_sync% must be
followed
+ by semicolon);
+ postfix_expression =
This patch modifies AVR target's ASM spec to pass -mlink-relax to the
assembler if -mrelax is passed to the compiler driver. This was already
being passed on to the linker, this patch merely makes the assembler
also aware of it.
The corresponding patch in binutils to handle the -mlink-relax patch
The DWARF bits are fine with me.
Thanks. Who can approve the other bits?
You should probably get C and C++ front end approval. I'm not really
sure who needs to review patches in c-family/. Since the part in c/ is
so tiny, maybe all you need is a C++ front end maintainer. Both
Richard Henderson
At the last C++ meeting I got the committee to accept wording that ought
to allow us to set DECL_IS_MALLOC on the built-in operator new:
Furthermore, for the library allocation functions in 18.6.1.1
[new.delete.single] and 18.6.1.2 [new.delete.array], p0 shall point to a
block of storage
Recent changes to the C++ standard have allowed the use of
list-initialization with a single initializer of the same type as the
target; this patch updates reshape_init accordingly.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 0bb6493b9f08021d00a636fe5b4ea777bd4cbc13
Author: Jason
As a followup to http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00079.html, which
implements the shuffle operation but still leaves that unused - if/once that's
gone in, I see no reason now we can't start using it, and enable the appropriate
tests. I see the following test changes:
FAIL-PASS:
When I fixed 60375, I noticed that we were giving the error multiple
times. We already have a mechanism for avoiding repeated diagnostics
for ambiguous lookup; this patch uses that mechanism for the lambda
error as well.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit
In the C front end, arrays used as expressions immediately decay to
pointers. In C++, they don't decay until we know that the expression is
being used as an rvalue, as we might want to bind a reference to the
array as a whole. The atomics code in c-common expects pointers, so
let's force any
Hi Richard,
This patch fixes a problem with the SW16, SH16 and SB16 microMIPS instructions.
GCC is incorrectly calculating the length of these instructions if $16 is used
as the source operand. The incorrect length calculation can cause a 32-bit
instruction to be placed in a short delay
On Wed, 26 Feb 2014, Paolo Carlini wrote:
On 02/26/2014 10:57 AM, Jonathan Wakely wrote:
On 24 February 2014 09:10, Paolo Carlini wrote:
Another option would be just using boost/multiprecision/mpfr.hpp when
available. In general, I think it makes sense to have a minimum of
infrastructure
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
http://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-4.9-b20140202.sv.po',
+ token = cp_lexer_peek_token (parser-lexer);
+ if (token-type != CPP_SEMICOLON)
+ {
+ error_at (token-location, %_Cilk_sync% must be
followed
+ by semicolon);
+ postfix_expression =
+
+ /* At this stage we know that majority of GGC memory is reachable.
+ Growing the limits prevents unnecesary invocation of GGC. */
+ ggc_grow ();
ggc_collect ();
Isn't the collect here pointless? I see not in ENABLE_CHECKING, but
shouldn't this be abstracted away,
On Wed, 5 Mar 2014, Jonathan Wakely wrote:
On 5 March 2014 19:36, Marc Glisse wrote:
Hello,
this issue got delayed in LWG, apparently because of a failed improvement
to the wording along the way (happens, that's ok), but there seems to be a
consensus on the resolution and I don't really see
Hi,
This commit added LIBITM_CHECK_AS_HTM to libitm/configure.ac, but did
not add it to acinclude.m4, so configure complains about an unrecognised
command (4.8 only). I don't know if LIBITM_CHECK_AS_HTM is supposed to
check anything that needs checking on 4.8, I just got confused by the
message.
Hi Catherine/Richard,
I think there may be some impact on register move costs by introducing this
class. Is it worth having mips_canonicalize_move_class return M16_REGS for
M16_STORE_REGS to reduce the effect on costings? Given the extra register is
only $0 then this would seem mostly
Hello,
the previous discussion on the topic was before we added all those #pragma
target in *mmintrin.h:
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00374.html
I believe that removes a large part of the arguments against it. Note that
I only did a few of the more obvious intrinsics, I am
Since fixuns_truncmodesi2 expander checks optimize_insn_for_size_p
before generating *fixuns_truncmode_1, we should use
optimize_insn_for_speed_p in *fixuns_truncmode_1 for consistency.
OK for trunk?
Thanks.
H.J.
---
2014-04-11 H.J. Lu hongjiu...@intel.com
PR target/60827
*
On Fri, Apr 11, 2014 at 1:36 AM, Bernd Edlinger
bernd.edlin...@hotmail.de wrote:
Hi Teresa,
@@ -1947,7 +1947,7 @@ remove_bb (basic_block bb)
fprintf (dump_file, Removing basic block %d\n, bb-index);
if (dump_flags TDF_DETAILS)
{
- dump_bb (dump_file, bb, 0,
Svante Signell, le Fri 11 Apr 2014 14:47:21 +0200, a écrit :
#ifdef TARGET_LIBC_PROVIDES_SSP
+/* i386 glibc provides __stack_chk_guard in %gs:0x14. */
+#define TARGET_THREAD_SSP_OFFSET 0x14
Err, not the Hurd variant, no. Is it really needed?
@@ -682,7 +686,7 @@
go_net_cgo_file =
On Mon, 31 Mar 2014, Dominique d'Humières wrote:
Updated gfortran.dg/fmt_en.f90 to skip some tests not
supported on i?86-*-solaris2.9* and hppa*-*-hpux* (these tests
assume rounding to nearest and to even on tie, AFAICT
i?86-*-solaris2.9* rounds real(16) to zero and hppa*-*-hpux*
rounds all
Thomas Schwinge, le Wed 09 Apr 2014 09:36:42 +0200, a écrit :
Well, the first step is to verify that TARGET_THREAD_SPLIT_STACK_OFFSET
and similar configury is correct for the Hurd,
It's not. I've checked what TARGET_THREAD_SPLIT_STACK_OFFSET is, it's
an offset inside the tcbhead_t structure,
Ping...
-Original Message-
From: Kapania, Ashish
Sent: Friday, April 04, 2014 4:53 PM
To: 'gcc-patches@gcc.gnu.org'
Subject: RE: [PATCH] (configure.ac) Add support for TI-RTOS
Forgot to attach the patch file :)
-Original Message-
From: Kapania, Ashish
Sent: Friday, April 04,
Samuel Thibault, le Fri 11 Apr 2014 23:51:44 +0200, a écrit :
So, do we really want to let munmap poke a hole at address 0 and thus
let further vm_map() return address 0?
i.e. we could apply this:
diff --git a/sysdeps/mach/munmap.c b/sysdeps/mach/munmap.c
index 57d99f9..a46e3f1 100644
---
I plan to commit the following patch to 4.10, 4.9, 4.8, and 4.7.
It is a partial revert of the patch to PR38199 which is an optimization of
internal unit reads.
The original patch was too aggressive. After this revert, I will investigate
further to see if I can refine it further.
Regards,
Relates to PR60810
On 04/11/2014 04:10 PM, Jerry DeLisle wrote:
I plan to commit the following patch to 4.10, 4.9, 4.8, and 4.7.
It is a partial revert of the patch to PR38199 which is an optimization of
internal unit reads.
The original patch was too aggressive. After this revert, I
Jerry DeLisle wrote:
I plan to commit the following patch to 4.10, 4.9, 4.8, and 4.7.
It is a partial revert of the patch to PR38199 which is an optimization of
internal unit reads.
The original patch was too aggressive. After this revert, I will investigate
further to see if I can refine it
On 04/11/2014 04:31 PM, Tobias Burnus wrote:
Jerry DeLisle wrote:
I plan to commit the following patch to 4.10, 4.9, 4.8, and 4.7.
It is a partial revert of the patch to PR38199 which is an optimization of
internal unit reads.
The original patch was too aggressive. After this revert, I
Hi,
The patch below addresses what I consider to be an obvious typo in
gcc/config/i386/cygwin-w64.h on trunk and gcc-4_9-branch
OK to commit to both branches?
Ralf
2014-04-12 Ralf Corsépius ralf.corsep...@rtems.org
* config/i386/cygwin-w64.h: Remove duplicate undef LONG_TYPE_SIZE.
69 matches
Mail list logo
