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
* config/i386/cygwin-w64.h: Remove duplicate undef LONG_TYPE_SIZE.
Index: gcc/config/i386/cygwin
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 r
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 f
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 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,
Jerr
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
--- a/s
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, 20
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,
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
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 Fri, Apr 11, 2014 at 1:36 AM, Bernd Edlinger
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, dump_flags);
Since fixuns_truncsi2 expander checks optimize_insn_for_size_p
before generating *fixuns_trunc_1, we should use
optimize_insn_for_speed_p in *fixuns_trunc_1 for consistency.
OK for trunk?
Thanks.
H.J.
---
2014-04-11 H.J. Lu
PR target/60827
* config/i386/i386.md (*fixuns_trun
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 wa
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 acceptabl
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.
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
> > +
> > + /* 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 abstract
>
> >> + token = cp_lexer_peek_token (parser->lexer);
> >> + if (token->type != CPP_SEMICOLON)
> >> + {
> >> + error_at (token->location, "%<_Cilk_sync%> must be
> >> followed"
> >> + " by semicolon");
> >> + post
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',
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 enabl
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 slot.
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
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 8e24a9920a302fe140
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:
g
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 Merr
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 disjo
>> 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 Hender
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
>
> >> + token = cp_lexer_peek_token (parser->lexer);
> >> + if (token->type != CPP_SEMICOLON)
> >> + {
> >> + error_at (token->location, "%<_Cilk_sync%> must be
> >> followed"
> >> + " by semicolon");
> >> + post
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 argum
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 sta
Ping?
On Fri, Mar 21, 2014 at 9:16 AM, Paul Pluzhnikov 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 once it opens in s
OK.
Jason
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)
+ {
+
On Fri, Apr 11, 2014 at 5:47 AM, Svante Signell
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 automake
> is no longer
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
fact.
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 actu
--- Begin Message ---
(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 differentl
--- Begin Message ---
(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 f
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
https://list
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_C
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 testcas
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
ma
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 inc
On Sat, Mar 29, 2014 at 10:51:58AM +0100, Tobias Burnus wrote:
> 2014-03-29 Tobias Burnus
>
> PR other/59055
> * doc/bugreport.texi (Bugs): Remove nodes pointing to the
> nirvana.
> * doc/gcc.texi (Service): Update description in the @menu
> * doc/invoke.texi (Opti
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, wi
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 w
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 x86_64-unk
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
* gcc.target/s390/htm-nofloat-1.c: Rename to ...
*
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
PR middle-end/607
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.
2014-04-1
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_ins
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
On 11 April 2014 00:10, Jakub Jelinek 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 gcc.dg/guality/pr36728-1
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 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
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_DETAI
On Thu, Apr 10, 2014 at 10:42 AM, Ramana Radhakrishnan 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.
On Tue, Apr 8, 2014 at 6:55 PM, Teresa Johnson 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 incoming edges
>
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
>
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 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?
Thank
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 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 symbol
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 int
65 matches
Mail list logo
