Hi Mikael, hi Jerry, hi Steve, hi Jane, hi Thomas, hi Paul, hi all,
thanks for all the input you gave on the patch I have present. I tried to
address all of it in the new version of the patch attached.
Mikael: data.c::create_character_initializer()
I have remove the test for rvalue->value.charact
Goo day!
Are there some news on this?
Can we apply docs (and tests, maybe) improvements from this patch?
--
Alexander Kurakin
Hi Andre,
Thanks for doing this work with the instrumented compiler. It was a
great help with PR78350.
As for the patch - OK for trunk.
Paul
On 11 December 2016 at 14:01, Andre Vehreschild wrote:
> Hi Mikael, hi Jerry, hi Steve, hi Jane, hi Thomas, hi Paul, hi all,
>
> thanks for all the input
On Thu, 8 Dec 2016, Josh Conner wrote:
This patch adds support to gcc for the Fuchsia OS
(https://fuchsia.googlesource.com/).
Once this is in, can you please suggest a news item for our
main page?
(You could cook a patch following https://gcc.gnu.org/about.html
or suggest wording or an HTML sn
On Fri, Dec 9, 2016 at 11:09 AM, Richard Biener
wrote:
> On Thu, Dec 8, 2016 at 10:44 PM, Uros Bizjak wrote:
>> Hello!
>>
>> Attached patch fixes fall-out from excess-precision improvements
>> patch. As shown in the PR, the code throughout the compiler assumes
>> FLAG_PRECISION_FAST when flag_uns
On Fri, Dec 9, 2016 at 11:49 PM, Allan Sandfeld Jensen
wrote:
> On Tuesday 06 December 2016, Uros Bizjak wrote:
>> Hello!
>>
>> > 2016-11-30 Allan Sandfeld Jensen
>> >
>> >PR target/70118
>> >* gcc/config/i386/mmintrin.h (__m64_u): New type
>> >* gcc/config/i386/emmintri
On Sun, 6 Nov 2016, Uros Bizjak wrote:
> Looks good to me, so OK if tested on non-glibc system.
Thanks, Uros!
Turns out at least in my testing our testsuite is a little non-
deterministic :-(, but after tests without the patch, with the
patch, again with the patch, and without the patch again o
> Jerry: trans-expr.c::gfc_conv_cst_int_power()
> I have added comment to new C++ code. Would you like to add something to it?
Note that the wi changes have occurred at revision r210113.
>
> The updated patch bootstraps and regtests fine on x86_64-linux/f23 on a
> regular
> and on an instrument
On Mon, 5 Dec 2016, Gerald Pfeifer wrote:
> Applied now, and more changes to follow later.
Done thusly, which removes quite a bit of the remaining bits.
Remove java/port-files.html, java/port-signals.html, java/port-threads.html,
java/libgcj-classpath-compare.html, java/merge-status.html and the
On Mon, 7 Nov 2016, Andreas Tobler wrote:
> Results w/o patch:
> https://gcc.gnu.org/ml/gcc-testresults/2016-11/msg00627.html
>
> Results with patch:
> https://gcc.gnu.org/ml/gcc-testresults/2016-11/msg00672.html
Thanks, Andreas, quite useful.
For reference, the reason I did not go ahead with th
Hello!
Attached patch improves cost function for STV transform of shifts with
constant count operand. The new cost function reduces the gain by
COST_N_INSN(1) for shifts larger than or equal to 32.
2016-12-11 Uros Bizjak
PR target/70799
* config/i386/i386.c (dimode_scalar_to_vector_ca
PR 16519 notes that -pthread has only ever been documented as an RS6000
and Solaris 2 option. In fact it's supported by most/all(?)
POSIX-flavored targets, including GNU/Linux, BSD variants, Darwin, etc.
It's probably best to document it as a generic option, with the
expectation that GCC supp
The attached change implements a new -mcaller-copies option on hppa. The
default 32-bit runtime
specifies that the callee copies arguments passed by hidden reference. This is
optimal but it causes
problems with openmp. See PR middle-end/68733:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68733
Hi,
PR78695 demonstrates a bug in swap analysis where we assume that a
data-flow definition contains a nonzero insn_info. This assumption
is wrong at least when -fstack-protector is in effect, as the
definition of the base register of the stack protector is not
associated with any insn. This pat
Hi Folks,
another from my darwin-ppc stack...
r239866 removed most of the uses of LR in returns and sibcalls
Darwin had an additional use of LR in the restore_world machinery. This patch
removes it
from the pattern in altivec.md and the relevant predicate.
OK / Comments?
Iain
gcc/
2016-12
Hi Bill,
On Sun, Dec 11, 2016 at 01:35:59PM -0600, Bill Schmidt wrote:
> --- gcc/config/rs6000/rs6000.c(revision 243506)
> +++ gcc/config/rs6000/rs6000.c(working copy)
> @@ -41433,6 +41433,12 @@ find_alignment_op (rtx_insn *insn, rtx base_reg)
>if (!base_def_link || base_de
Hi Sandra,
> PR 16519 notes that -pthread has only ever been documented as an RS6000 and
> Solaris 2 option. In fact it's supported by most/all(?) POSIX-flavored
> targets, including GNU/Linux, BSD variants, Darwin, etc. It's probably best
> to document it as a generic option, with the expectatio
Hi Kelvin,
On Fri, Dec 09, 2016 at 11:39:36AM -0700, Kelvin Nilsen wrote:
> +#ifndef HAVE_AS_POWER9
> +#define HAVE_AS_POWER9 0
> +#endif
> +#ifndef HAVE_AS_POWER8
> +#define HAVE_AS_POWER8 0
> +#endif
> +#ifndef HAVE_AS_POPCNTD
> +#define HAVE_AS_POPCNTD 0
> +#endif
> +#ifndef HAVE_AS_DFP
> +#def
On 12/11/2016 01:28 PM, Rainer Orth wrote:
Hi Sandra,
PR 16519 notes that -pthread has only ever been documented as an RS6000 and
Solaris 2 option. In fact it's supported by most/all(?) POSIX-flavored
targets, including GNU/Linux, BSD variants, Darwin, etc. It's probably best
to document it as
Hi Segher,
On 12/11/16 2:00 PM, Segher Boessenkool wrote:
> Maybe this should use DF_REF_IS_ARTIFICIAL? Or if that doesn't work,
> DF_REF_INSN_INFO?
>
OK, currently regstrapping the following, which also fixes the problem with
a non-bootstrap compiler. Is this ok for trunk if it succeeds?
Thank
Hello world,
the attached patch fixes a 5/6/7 regression with -fimplicit-none.
Regression-tested. OK for all affected branches?
Regards
Thomas
2016-12-11 Thomas Koenig
PR fortran/78239
* decl.c(char_len_param_value): Also check for -fimplicit-none
when det
Hi Segher,
This indeed bootstrapped on powerpc64le-unknown-linux-gnu with no
regressions. Ok for trunk?
Thanks for the review!
Bill
On 12/11/16 3:31 PM, Bill Schmidt wrote:
> Hi Segher,
>
> On 12/11/16 2:00 PM, Segher Boessenkool wrote:
>> Maybe this should use DF_REF_IS_ARTIFICIAL? Or if th
On Sun, Dec 11, 2016 at 03:31:35PM -0600, Bill Schmidt wrote:
> On 12/11/16 2:00 PM, Segher Boessenkool wrote:
> > Maybe this should use DF_REF_IS_ARTIFICIAL? Or if that doesn't work,
> > DF_REF_INSN_INFO?
> >
> OK, currently regstrapping the following, which also fixes the problem with
> a non-bo
Ah, I misread your comment and went hunting for DF_REF_ARTIFICIAL. Sorry!
Will fix.
Thanks again,
Bill
> On Dec 11, 2016, at 5:29 PM, Segher Boessenkool
> wrote:
>
> On Sun, Dec 11, 2016 at 03:31:35PM -0600, Bill Schmidt wrote:
>> On 12/11/16 2:00 PM, Segher Boessenkool wrote:
>>> Maybe thi
So I think the return value needs a bit of clarification here. Take
guidance from our discussion on this thread.
OK with that fixed.
jeff
The "strange test failures" that I wrote about in a separate thread
late last week prompted me to re-review the patch and add more test
cases. Those in t
Since the last time I built GCC for nios2-linux-gnu target, it had
started dying while building libgcc, with an ICE complaining about
shared rtx structure in a CONST expression involving
UNSPEC_PIC_CALL_SYM. I tracked it down to failing to copy the source
rtx for one of the pieces of a hi/lo r
On 12/11/2016 12:30 PM, John David Anglin wrote:
+@item -mcaller-copies
+@opindex mcaller-copies
+The caller copies function arguments passed by hidden reference. This
+option should be used with care as it is not compatible with the default
+32-bit runtime. However, only aggregates larger tha
On 2016-12-11, at 9:22 PM, Sandra Loosemore wrote:
> Please fix this to spell "OpenMP" correctly.
Done.
--
John David Anglin dave.ang...@bell.net
Hi,
Please find attached the patch that implements the support for popcount
patterns in AArch64.
The implementation improves OVS-DPDK on ThunderX by 3%. It would have a
similar effect on other AArch64 targets.
Please review the patch and let us know if its okay?
2016-12-12 Andrew Pinski
gcc
Ping...
On 12/05/16 14:41, Bernd Edlinger wrote:
> Hi,
>
> this was the latest version of my patch:
> https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02796.html
>
>
> Thanks
> Bernd.
The main purpose of the T constraint is to make sure that a memory reference
is aligned on a 64-bit boundary in 32-bit mode. But define_memory_constraint
is not appropriate for such a constraint, because reload may think that it can
satisfy it by reloading the address, which is of course wrong;
Hi Richard,
I am fine with the new patch but you'll need an approval from Honza
or Richi.
I find it a bit saddening that we cannot really rely on
gimple_call_fntype but at least I do not see any other way.
The patch looks somewhat backward. It populates the param type from
the callee but the
32 matches
Mail list logo