2015-01-15 Martin Uecker
* MAINTAINERS: (Write After Approval): Add myself.
Index: MAINTAINERS
===
--- MAINTAINERS (Revision 219713)
+++ MAINTAINERS (Revision 219714)
@@ -576,6 +576,7 @@
Philipp Tomsich
Hi,
I think I should ping for this patch now:
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00599.html
note that by mistake the change log referenced sanitizer.c instead of
sanitizer.def, consider that fixed on my local copy.
Thanks
Bernd.
> Date: Sun, 11 Jan 2015 14:15:54 +0100
>
> Hi,
>
>
Hi jeff and Richard
On 15 January 2015 at 03:10, Jeff Law wrote:
> On 01/14/15 04:27, Venkataramanan Kumar wrote:
>>
>> Hi all,
>>
>> When trying to debug GCC combiner pass with the test case in PR63949
>> ref https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63949 I came across this
>> code.
>>
>> Th
On 01/15/15 16:43, Nathaniel Smith wrote:
Jakub, myself and management have discussed this issue extensively and those
patches specifically. I'm painfully aware of how this affects the ability
to utilize numerical packages in Python.
Thanks for the response! I had no idea anyone was paying at
This was really just a formality given Eric's existing maintainer
positions ;-)
I'm pleased to announce that Eric Botcazou has been appointed as the
maintainer for the Visium port.
Jeff
I merged trunk revision 219701 to the gccgo branch.
Ian
2015-01-14 17:58 GMT+08:00 Chung-Ju Wu :
> Hi, all,
>
> In this patch of nds32 port:
> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00969.html
>
> Since we remove the implementation of -mforce-fp-as-gp, -mforbid-fp-as-gp,
> and -mex9 options, we need to update documentation as well.
> The patch
2015-01-14 17:56 GMT+08:00 Chung-Ju Wu :
> Hi, all,
>
> In this patch of nds32 port:
> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00799.html
>
> Since we have a new option -mcmodel= as substitution for -mgp-direct,
> we need to update documentation about such change accordingly.
> The patch is
Hi, all,
I just happened to notice that there are some incorrect date
in ChangeLog files. I guess this can be considered as obvious fix.
Committed it as Rev.219704: https://gcc.gnu.org/r219704
Index: gcc/ChangeLog
===
--- gcc/Chang
OK.
Jason
Hi,
after some testing on firefox, SPEC and C++ benchmark I decided to bump up
early-inlining-insns somewhat because I find inliner decisions to be
considerably
more robust this way allowing me to reduce inline-unit-growth.
There are several reasons for increasing early-inliner's activity. First
On 01/15/2015 09:58 PM, Aldy Hernandez wrote:
The attached patch generates early DIEs for the C++
clones in the C++ parser.
This strikes me as an unnecessary abstraction violation.
+ /* Emit debug information for clones. */
+ symtab_node *node;
+ FOR_EACH_DEFINED_SYMBOL (node)
+if (DE
Hi,
this patch fixes ICE during profiledbootstrap. The underlying problem is
somewhat hard
to fix (and not too important), so I will pospone it for next stage1.
Honza
Index: ChangeLog
===
--- ChangeLog (revision 219700)
+++ Change
Hi Jason. Hi Richard.
While adjusting the limbdo_die_list for early debug I noticed we weren't
early generating C++ constructors/destructors. This got me on a detour
of sorts.
I noticed dwarf2out's gen_member_die() disallows generation of clones
earlier, by design:
/* Don't include
The recent libffi upgrade caused one of the 32-bit x86 libgo tests to
break. The problem case is a function that returns an empty struct--a
struct with no fields. The libffi library does not recognize the
existence of empty structs, presumably since they can't happen in C.
To work around this, th
On Fri, Jan 16, 2015 at 5:04 AM, Jeff Law wrote:
>
> Stage3 is closing rapidly. I've drained my queue of patches I was tracking
> for gcc-5.However, note that I don't track everything. If it's a patch
> for a backend, language other than C or seemingly has another maintainer
> that's engaged
This patch is for PR 59710. As noted in that issue, the nios2 backend
only uses GP-relative addressing on objects defined locally to the
translation unit, where it knows definitely that the object is assigned
to the small data section under the current -G setting. Some other
backends also use
Hi Jeff,
On Thu, Jan 15, 2015 at 10:50 PM, Jeff Law wrote:
> On 01/15/15 15:34, Nathaniel Smith wrote:
>>
>> On Thu, Jan 15, 2015 at 9:04 PM, Jeff Law wrote:
>>>
>>>
>>> Stage3 is closing rapidly. I've drained my queue of patches I was
>>> tracking
>>> for gcc-5.However, note that I don't t
On Thu, Jan 15, 2015 at 3:00 PM, Richard Henderson wrote:
> On 01/15/2015 02:47 PM, H.J. Lu wrote:
>> On Thu, Jan 15, 2015 at 8:40 AM, Rainer Orth
>> wrote:
>>> Richard Henderson writes:
>>>
Upstream libffi has added support for Go closures (using the static chain),
and support for com
Hi,
can_remove_node_now_p assumes that the node in question has no direct calls,
this
however is not checked in inline_call that leads to alias to be removed from
comdat group while it should not.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
PR ipa/64612
* ipa-inline-tra
On 01/15/2015 02:47 PM, H.J. Lu wrote:
> On Thu, Jan 15, 2015 at 8:40 AM, Rainer Orth
> wrote:
>> Richard Henderson writes:
>>
>>> Upstream libffi has added support for Go closures (using the static chain),
>>> and support for complex numbers. Perhaps less relevant is new support for
>>> arc, mi
On 01/15/15 15:34, Nathaniel Smith wrote:
On Thu, Jan 15, 2015 at 9:04 PM, Jeff Law wrote:
Stage3 is closing rapidly. I've drained my queue of patches I was tracking
for gcc-5.However, note that I don't track everything. If it's a patch
for a backend, language other than C or seemingly h
On Thu, Jan 15, 2015 at 8:40 AM, Rainer Orth
wrote:
> Richard Henderson writes:
>
>> Upstream libffi has added support for Go closures (using the static chain),
>> and support for complex numbers. Perhaps less relevant is new support for
>> arc, microblaze, moxie, nios, and or1k targets.
>>
>> W
On 14.01.15 10:43, Richard Earnshaw wrote:
On 13/01/15 21:08, Andreas Tobler wrote:
On 13.01.15 11:25, Ramana Radhakrishnan wrote:
On Thu, Jan 8, 2015 at 8:51 PM, Andreas Tobler wrote:
On 08.01.15 17:27, Richard Earnshaw wrote:
On 29/12/14 18:44, Andreas Tobler wrote:
All,
here is the th
On Thu, Jan 15, 2015 at 9:04 PM, Jeff Law wrote:
>
> Stage3 is closing rapidly. I've drained my queue of patches I was tracking
> for gcc-5.However, note that I don't track everything. If it's a patch
> for a backend, language other than C or seemingly has another maintainer
> that's engaged
Hi Thomas,
thanks to you and all others involved for the OpenACC merge.
Attached is a patch which converts for Fortran '%s' into %qs, as
mentioned to before. (It wasn't possible when the original patch was
reviewed as the common diagnostic patches came later.)
Committed as Rev. 219694.
On
Jakub Jelinek writes:
> On Tue, Jan 13, 2015 at 05:06:35PM +, Richard Sandiford wrote:
>> Jakub Jelinek writes:
>> > Patch too large to attach uncompressed, this
>> > has been created with update-copyright.py --this-year.
>> > Note, I had to temporarily move away gcc/jit/docs/conf.py,
>> > th
All of this has been posted before.
I believe the ABI change is something we should have for gcc 5.
Yes, the libffi merge has been causing problems (on targets that
don't even support libgo, annoyingly), but missing support for
the new libffi interfaces is easier to remedy in a dot release
than t
On Wed, Jan 14, 2015 at 11:07 AM, Uros Bizjak wrote:
>
>> This patch adds support to the GCC tree for building tools that are
>> used with Go. There are two external used tools (go, gofmt) and one
>> tool used internally by go (cgo). This patch is pure machinery, with
>> no source code. The too
On Thu, 15 Jan 2015, Jiong Wang wrote:
> + if (bitsize + bitnum > unit && bitnum < unit)
> +{
> + warning (OPT_Wextra, "write of "HOST_WIDE_INT_PRINT_UNSIGNED"bit data "
> +"outside the bound of destination object, data truncated into "
> +HOST_WIDE_INT_PRINT_UNSI
On 15.01.2015 17:01, Ian Lance Taylor wrote:
> On Wed, Jan 14, 2015 at 11:54 PM, Patrick Wollgast
> wrote:
>> Is there something I'm still supposed to do, since I don't have write
>> access and this was the last part missing an "OK"?
>
> Somebody with write access will need to commit the patch fo
On January 15, 2015 9:05:59 PM CET, David Malcolm wrote:
>Release managers: given that this only touches the jit, and that the
>jit
>is off by default, any objections if I go ahead and commit this?
>It's a late-breaking feature, but the jit as a whole is new, and
>I think the following is a big wi
On Thu, 15 Jan 2015, Jakub Jelinek wrote:
> --- libcpp/expr.c.jj 2015-01-14 11:01:34.0 +0100
> +++ libcpp/expr.c 2015-01-14 14:35:52.851002344 +0100
> @@ -672,16 +672,17 @@ cpp_classify_number (cpp_reader *pfile,
>if ((result & CPP_N_WIDTH) == CPP_N_LARGE
> && CPP_OPTI
On Thu, Jan 15, 2015 at 1:04 PM, Jeff Law wrote:
>
> Stage3 is closing rapidly. I've drained my queue of patches I was tracking
> for gcc-5.However, note that I don't track everything. If it's a patch
> for a backend, language other than C or seemingly has another maintainer
> that's engaged
On Thu, Jan 15, 2015 at 8:30 AM, Rainer Orth
wrote:
>
> Apart from that, bootstrap fails in gotools: due to the use of
> -static-libgo, all commands there fail to link since the socket
> functions are missing. It seems like $LIBS from libgo needs to be added
> somewhere, but I'm unsure how best t
Stage3 is closing rapidly. I've drained my queue of patches I was
tracking for gcc-5.However, note that I don't track everything. If
it's a patch for a backend, language other than C or seemingly has
another maintainer that's engaged in review, then I haven't been
tracking the patch.
Applied, thanks.
Jason
On Jan 15, 2015, at 11:54 AM, Ilya Verbin wrote:
> On 15 Jan 11:20, Mike Stump wrote:
>> On Jan 15, 2015, at 9:53 AM, Ilya Verbin wrote:
>>> If I just remove 'load_gcc_lib gcc-dg.exp' from libatomic.exp, like this is
>>> done
>>> in libitm.exp, it will not work:
>>
>> Ok, original patch is fine
On Thu, Jan 15, 2015 at 8:30 AM, Rainer Orth
wrote:
>
> This (and perhaps the previous gotools) patch broke Solaris bootstrap:
>
> /vol/gcc/src/hg/trunk/local/libgo/go/net/tcpsockopt_unix.go:23:73: error:
> reference to undefined identifier 'syscall.TCP_KEEPINTVL'
> if err := syscall.Setsockopt
Normally when we see a call to a function with a reference parameter,
we've converted the argument to have reference type as well, so we can
always treat arguments as rvalues in potential_constant_expression. But
with templates we defer the conversions until instantiation time, so we
shouldn't
On Thu, Jan 15, 2015 at 9:45 AM, Jakub Jelinek wrote:
> On Thu, Jan 15, 2015 at 01:58:43PM +0100, Richard Biener wrote:
>> [ 5286s] ../../../libgo/go/reflect/makefuncgo_s390x.go:323:5: error:
>> expected ';
>> ' or '}' or newline
>> [ 5286s]} else {
>> [ 5286s] ^
>
> Bet that
> } else {
On 01/15/15 13:20, Thomas Schwinge wrote:
Hi!
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 who has
been contributing!
Note that this is an experimental feature, incomplete, and subject to
change in future
On Thu, Jan 15, 2015 at 03:05:59PM -0500, David Malcolm wrote:
> Release managers: given that this only touches the jit, and that the jit
> is off by default, any objections if I go ahead and commit this?
> It's a late-breaking feature, but the jit as a whole is new, and
> I think the following is
Release managers: given that this only touches the jit, and that the jit
is off by default, any objections if I go ahead and commit this?
It's a late-breaking feature, but the jit as a whole is new, and
I think the following is a big win, so I'd like to proceed with this in
stage 3 (i.e. in the nex
On 15 Jan 11:20, Mike Stump wrote:
> On Jan 15, 2015, at 9:53 AM, Ilya Verbin wrote:
> > If I just remove 'load_gcc_lib gcc-dg.exp' from libatomic.exp, like this is
> > done
> > in libitm.exp, it will not work:
>
> Ok, original patch is fine.
Oh, I see, it's loaded by libitm/testsuite/libitm.c/
gcc_jit_block_add_assignment_op was missing type-checking on the params,
which could lead to an ICE deep inside gimplification in fold-const.c:
10339 gcc_assert (TYPE_PRECISION (atype) == TYPE_PRECISION (type));
Takes jit.sum's # of expected passes from 7494 to 7514.
Committed to trunk as r2196
r219655 added two files explow.h, dojump.h with duplicated contents,
silly mistake from my side. The attached patch removes duplicate
contents. Committed (r219680) as obvious.
Thanks,
Prathamesh
2015-01-15 Prathamesh Kulkarni
* explow.h: Remove duplicate contents.
* dojump.h: L
Richard,
Thanks for catching this.
Your change is optimal for X-Gene 1.
—Phil.
> On 15 Jan 2015, at 19:51, Richard Earnshaw wrote:
>
> The recent xgene tuning parameters merge broke the ARM bootstrap, since
> the tables have been extended by an additional parameter giving:
>
> gcc/config/arm/
On Jan 15, 2015, at 9:53 AM, Ilya Verbin wrote:
> If I just remove 'load_gcc_lib gcc-dg.exp' from libatomic.exp, like this is
> done
> in libitm.exp, it will not work:
Ok, original patch is fine.
On 16 January 2015 at 00:00, Steve Ellcey wrote:
>
>> >>
>> >> 2015-01-14 Steve Ellcey
>> >>
>> >> * Makefile.in (PLUGIN_HEADERS): Add dominance.h, cfg.h, cfgrtl.h,
>> >> cfganal.h, cfgbuild.h, cfgcleanup.h, lcm.h, builtins.def,
>> >> chkp-builtins.def, and pass-instance
On Thu, Jan 15, 2015 at 09:55:40PM +0300, Ilya Verbin wrote:
> This patch enables 'make check-target-libgomp' with noninstalled offloading
> compilers. It creates gcc/accel// directory in the build tree of the
> offloading compiler, this allows lto-wrapper to find corresponding mkoffload
> in
> c
On 22 Dec 13:35, Jakub Jelinek wrote:
> On Mon, Dec 22, 2014 at 12:48:08PM +0100, Thomas Schwinge wrote:
> > In my understanding, we'd like to support the modes that either all
> > compilers are installed (which is what a user will be using), or all are
> > tested from their build trees. Or, do we
The recent xgene tuning parameters merge broke the ARM bootstrap, since
the tables have been extended by an additional parameter giving:
gcc/config/arm/arm.c:1932:1: error: missing initializer for member
'tune_params::fuseable_ops' [-Werror=missing-field-initializers]
};
^
Fixed as below. I'v
Similar to the unroll_1.c change.
* gcc.dg/inline_1.c: Rename gcc.dg/inline_[1-4].c to inline-3[6-9].c.
* gcc.dg/inline_2.c: Likewise.
* gcc.dg/inline_3.c: Likewise.
* gcc.dg/inline_4.c: Likewise.
On 11/20/14 05:33, Bernd Schmidt wrote:
Now that I've managed to put together and test all the submitted OpenACC
patches I found there was one piece missing. The problem is that omp-low
on the host likes to generate function names like "_main._omp_fn". On
ptx, the dot is not allowed in identifier
On 01/05/15 21:01, Hans-Peter Nilsson wrote:
On Fri, 14 Nov 2014, Radovan Obradovic wrote:
index eb37bfe..ddaf8e0 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -1605,6 +1612,11 @@ process_options (void)
/* Save the current optimization options. */
optimization_default_node = build_
2015-01-15 14:22 GMT+01:00 Mikael Morin :
the attached patch fixes an ICE-on-invalid problem with
procedure-pointer components by making sure that we continue resolving
all components of a derived type, even after an error is thrown.
>>> Does the fonction return false as before,
> >>
> >> 2015-01-14 Steve Ellcey
> >>
> >> * Makefile.in (PLUGIN_HEADERS): Add dominance.h, cfg.h, cfgrtl.h,
> >> cfganal.h, cfgbuild.h, cfgcleanup.h, lcm.h, builtins.def,
> >> chkp-builtins.def, and pass-instances.def
> >>
> Should pass-instances.def be removed from Ch
So, I wanted to add some unrolling test cases and found that we had unroll-1.c
and unroll_[1-5].c. :-( - is the standard, and picking numbers sequential
from 1, with a - before the number is standard. No reason to deviate in this
case. I’ve fixed this by renaming the test cases like so:
On 01/15/15 09:27, Jiong Wang wrote:
On 15/01/15 03:51, Jeff Law wrote:
On 01/14/15 15:31, Jiong Wang wrote:
agree, and I think the truncation is needed otherwise there may have ICE
on some target.
and I found current gcc LOCATION info is very good !
have done an experimental hack on at "expa
Oops, got a bit excessive with the copy/paste.
commit 4203eda52ae9eefc618d3819a3c468841bf2910b
Author: Jason Merrill
Date: Wed Jan 14 23:58:50 2015 -0500
PR c++/64356
* constexpr.c (cxx_eval_binary_expression): Fix pasto.
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index e
On 15 January 2015 at 14:14, Richard Biener wrote:
> On Wed, Jan 14, 2015 at 10:43 PM, Steve Ellcey wrote:
>> I tried compiling an empty plugin that just included gcc-plugin.h and
>> plugin-version.h and found that these header files were included from
>> gcc-plugin.h but not in the list of heade
On 12/15/2014 12:41 AM, Zhenqiang Chen wrote:
> +(define_expand "cmp"
> + [(set (match_operand 0 "cc_register" "")
> +(match_operator:CC 1 "aarch64_comparison_operator"
> + [(match_operand:GPI 2 "register_operand" "")
> + (match_operand:GPI 3 "aarch64_plus_operand" "")]))]
On 01/15/15 09:20, Rainer Orth wrote:
Martin Liška writes:
On 01/07/2015 12:38 PM, Martin Liška wrote:
Hello.
Following patch adds support for target and optimization nodes
comparison, which is
based on Honza's newly added infrastructure.
Apart from that, there's a small hunk that corrects
On 01/15/15 01:13, Jakub Jelinek wrote:
The glibc barriers are supposedly something that can be CSEd (one barrier
instead of
two consecutive barriers is enough), but certainly not moved across any
loads/stores
in between. In the kernel case, the enable/disable probably wouldn't allow
even CS
On 01/15/15 05:23, H.J. Lu wrote:
Hi,
libitm.c/stackundo.c fails with -fpic since test1 and test2 may be
preempted with -fpic. This patch makes those 2 functions static.
Tested on Linux/x86. OK for trunk?
Thanks.
H.J.
diff --git a/libitm/ChangeLog b/libitm/ChangeLog
index 74e2940..e468
On Thu, Jan 15, 2015 at 9:19 AM, Richard Henderson wrote:
> On 01/15/2015 08:54 AM, H.J. Lu wrote:
>> On Thu, Jan 15, 2015 at 8:40 AM, Rainer Orth
>> wrote:
>>> Richard Henderson writes:
>>>
Upstream libffi has added support for Go closures (using the static chain),
and support for com
On 15 Jan 09:40, Mike Stump wrote:
> On Jan 15, 2015, at 8:14 AM, Ilya Verbin wrote:
> > The problem is that gcc-dg.exp calls check_effective_target_lto, which calls
> > libatomic_target_compile. Therefore gcc-dg.exp should be loaded only after
> > the
> > definition of libatomic_target_compile.
On Thu, Jan 15, 2015 at 01:58:43PM +0100, Richard Biener wrote:
> [ 5286s] ../../../libgo/go/reflect/makefuncgo_s390x.go:323:5: error: expected
> ';
> ' or '}' or newline
> [ 5286s]} else {
> [ 5286s] ^
Bet that
} else {
line should have been replaced with
default:
Jakub
On 01/15/2015 08:54 AM, H.J. Lu wrote:
> On Thu, Jan 15, 2015 at 8:40 AM, Rainer Orth
> wrote:
>> Richard Henderson writes:
>>
>>> Upstream libffi has added support for Go closures (using the static chain),
>>> and support for complex numbers. Perhaps less relevant is new support for
>>> arc, mi
On Jan 15, 2015, at 8:14 AM, Ilya Verbin wrote:
> The problem is that gcc-dg.exp calls check_effective_target_lto, which calls
> libatomic_target_compile. Therefore gcc-dg.exp should be loaded only after
> the
> definition of libatomic_target_compile.
> However, a similar exp file in other tree
On Jan 15, 2015, at 7:28 AM, Eric Botcazou wrote:
> The attached patch fixes it by ensuring that LTO_TORTURE_OPTIONS is computed
> after set_ld_library_path_env_vars is invoked (this procedure invokes in turn
> set_gcc_exec_prefix_env_var), both in c-torture.exp and in gcc-dg.exp.
> OK for the
On 01/15/15 04:19, Jakub Jelinek wrote:
Hi!
With the addition of build libcpp, my build failed because of distro default
flags of -Werror=format-security.
The first hunk is I think no big deal, making it const makes the warning
go away.
The second hunk is more controversial, as even making mes
On 01/15/15 03:13, Robert Suchanek wrote:
Robert, can you look at reload.c::reload_inner_reg_of_subreg and verify
that the comment just before its return statement is effectively the
situation you're in.
There are certainly cases where a SUBREG needs to be treated as an
in-out operand. We walke
Hello.
This is Honsa's patch that I've just tested on x86_64-linux-pc. The patch is
preapproved by Honza
and is going to be installed.
Thanks,
Martin
>From 84b6878f168802516febfbd00252f56f965b9666 Mon Sep 17 00:00:00 2001
From: mliska
Date: Thu, 15 Jan 2015 17:20:00 +0100
Subject: [PATCH] Fix
On 01/15/2015 08:40 AM, Rainer Orth wrote:
> The patch introduced massive problems on Solaris, both SPARC and x86:
>
> * on Solaris/SPARC, /bin/as requires
>
> .type fn,#function
>
> instead of @function. I've simply commented the affected lines in
> src/sparc/v[89].S to make progress.
>
On Thu, Jan 15, 2015 at 8:30 AM, H.J. Lu wrote:
> On Thu, Jan 15, 2015 at 8:24 AM, Mike Stump wrote:
>> So, I was hoping that someone would step forward and review this. I’d like
>> for a reviewer to consider, is this the type of error messages we want to
>> vend to the poor user? It strikes
OK, sorry for the delay.
Jason
On Thu, Jan 15, 2015 at 8:40 AM, Rainer Orth
wrote:
> Richard Henderson writes:
>
>> Upstream libffi has added support for Go closures (using the static chain),
>> and support for complex numbers. Perhaps less relevant is new support for
>> arc, microblaze, moxie, nios, and or1k targets.
>>
>> W
Richard Henderson writes:
> Upstream libffi has added support for Go closures (using the static chain),
> and support for complex numbers. Perhaps less relevant is new support for
> arc, microblaze, moxie, nios, and or1k targets.
>
> Without additional changes for Go, this merge has little effec
On 01/15/15 09:36, Zamyatin, Igor wrote:
On 01/13/15 11:01, Zamyatin, Igor wrote:
Is it really sufficient here to verify that all the defs are on latch
predecessors, what about the case where there is a predecessor
without a def. How do you guarantee domination in that case?
ISTM that given
>
> On 01/13/15 11:01, Zamyatin, Igor wrote:
> >>
> >> Is it really sufficient here to verify that all the defs are on latch
> >> predecessors, what about the case where there is a predecessor
> >> without a def. How do you guarantee domination in that case?
> >>
> >> ISTM that given the structur
On Jan 14, 2015, at 6:52 AM, Richard Earnshaw wrote:
> On 14/01/15 11:57, Thomas Preud'homme wrote:
>> Ping?
>
> I'm OK with this, but I think you also need a generic testsuite
> maintainer to go over the target independent parts.
Ok.
On Thu, Jan 15, 2015 at 8:24 AM, Mike Stump wrote:
> So, I was hoping that someone would step forward and review this. I’d like
> for a reviewer to consider, is this the type of error messages we want to
> vend to the poor user? It strikes me as, well, icky. Should -fPIE imply
> -fPIC?
It i
Ian Lance Taylor writes:
> I've committed a patch to libgo to update it to the Go 1.4 release,
> except for the runtime package. Much of the runtime package was
> rewritten in Go, and it does not really affect users of the library,
> so I've postponed that complex merge. All the other packages
On 15/01/15 03:51, Jeff Law wrote:
On 01/14/15 15:31, Jiong Wang wrote:
agree, and I think the truncation is needed otherwise there may have ICE
on some target.
and I found current gcc LOCATION info is very good !
have done an experimental hack on at "expand_assignment": 4931 where the
tree is
So, I was hoping that someone would step forward and review this. I’d like for
a reviewer to consider, is this the type of error messages we want to vend to
the poor user? It strikes me as, well, icky. Should -fPIE imply -fPIC?
Exclusive of that issue, the patch is fine.
On Jan 11, 2015, at
On 01/15/2015 05:20 PM, Rainer Orth wrote:
Martin Liška writes:
On 01/07/2015 12:38 PM, Martin Liška wrote:
Hello.
Following patch adds support for target and optimization nodes
comparison, which is
based on Honza's newly added infrastructure.
Apart from that, there's a small hunk that corr
Martin Liška writes:
> On 01/07/2015 12:38 PM, Martin Liška wrote:
>> Hello.
>>
>> Following patch adds support for target and optimization nodes
>> comparison, which is
>> based on Honza's newly added infrastructure.
>>
>> Apart from that, there's a small hunk that corrects formatting and
>> rem
On Jan 14, 2015, at 3:50 AM, Tejas Belagod wrote:
> As agreed here (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63971), please
> can I reverse Andrew's patch
> out(https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02916.html)?
Ok.
Unless someone objects to a reversion like this, when the author o
Hi!
This patch fixes 'make check-target-libatomic'.
The problem is that gcc-dg.exp calls check_effective_target_lto, which calls
libatomic_target_compile. Therefore gcc-dg.exp should be loaded only after the
definition of libatomic_target_compile.
However, a similar exp file in other tree (libi
On 14/01/15 02:20 PM, Robert Suchanek wrote:
> Hi Vladimir,
>
> An issue has been identified with LRA when running CPU2006 h264ref benchmark.
>
> I'll try to describe what the issue is and a fix applied as it is very
> difficult to reproduce it and it is next to impossible to create a narrowed
> te
On Wed, Jan 14, 2015 at 8:14 PM, Segher Boessenkool
wrote:
> This fixes 141 FAILs.
>
> -mpowerpc64 does not change the ABI, but default_scalar_mode_supported_p
> does not know that, and allows TImode for -m32 -mpowerpc64.
>
> This fixes it. Okay for mainline?
>
>
> 2015-01-14 Segher Boessenkool
On Wed, Jan 14, 2015 at 11:54 PM, Patrick Wollgast
wrote:
> Is there something I'm still supposed to do, since I don't have write
> access and this was the last part missing an "OK"?
Somebody with write access will need to commit the patch for you. You
should send a new clean patch including all
Hello.
Following patch is a backport of PR lto/63704 for GCC 4.8 and 4.9 branches.
Richi preapproved me the patch and I've run regtests on x86_64-linux-pc.
I'm going to install the patch.
Thanks,
Martin
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 779fef7..ab916b8 100644
--- a/gcc/ChangeLog
On Wed, 2015-01-14 at 13:36 -0700, Jeff Law wrote:
> On 01/14/15 13:32, David Edelsohn wrote:
> > The PPC64LE ABI specifies POWER8 ISA as the minimum hardware
> > requierment. Currently, Linux distributions are building the
> > toolchain using --with-cpu=power7 or power8, as they wish. GCC
> > de
Hi,
if you run a test for a bareboard port, e.g. arm-eabi or visium-elf, you'll
see in gcc.log:
Running /home/eric/svn/gcc/gcc/testsuite/gcc.dg/dg.exp ...
Executing on host: /home/eric/build/gcc/arm-eabi/gcc/xgcc -
B/home/eric/build/gcc/arm-eabi/gcc/ linker_plugin14260.c -fno-diagnostics-
show-
Hi all,
This test is applicable to aarch64 target. This patch will remove
aarch64 from skip target list.
Verified that it passes for aarch64-none-elf and aarch64-none-linux-gnu
target.
Okay for trunk?
gcc/testsuite/ChangeLog:
2015-01-15 Renlin Li
* gcc.dg/builtin-apply2.c: Remov
On 15/12/14 08:41, Zhenqiang Chen wrote:
-Original Message-
From: Richard Henderson [mailto:r...@redhat.com]
Sent: Saturday, December 13, 2014 3:26 AM
To: Zhenqiang Chen
Cc: Marcus Shawcroft; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH, AARCH64] Fix ICE in CCMP (PR64015)
- tr
On Thu, Jan 15, 2015 at 3:17 PM, Ilya Tocar wrote:
> Hi,
> Looks like new ISA doc [1] renamed srli,slli intrinsics to bsrli,bslli.
> This patch adds b* versions, while keeping old srli for backward
> compatibility.
> OK for trunk?
>
> 1:https://software.intel.com/sites/default/files/managed/0d/53/
1 - 100 of 143 matches
Mail list logo