The following patches have remained unreviewed for two weeks despite a
reminder:
[build] Support --sysroot with Solaris ld
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg02342.html
This needs a build maintainer, though I still think it could be
considered obvious.
Support
Updated the patch to more fully address the reload_completed issues raised by
Richard, to ensure that the SIMD patterns are not used for shifts and fixed a
code generation bug.
Okay for trunk?
Bootstrapped and tested on aarch64-linux-gnu. Okay for trunk?
2017-05-22 Kyrylo Tkachov
crtl->is_leaf has a comment above it referring to "Local Register
Allocation". However this is set by IRA and not LRA since the meaning of
Local Register Allocator in GCC has changed quite drastically since 1999
when this comment was introduced above the variable
current_function_is_leaf. From
On 14/06/17 18:03, Richard Earnshaw (lists) wrote:
On 14/06/17 17:49, Thomas Preudhomme wrote:
Hi,
Testcase gcc.target/arm/its.c was added as part of a patch [1] to limit
IT blocks to 2 instructions maximum. However, the patch was only tested
indirectly by *aiming* to check that the assembly
On 15/06/17 09:18, Thomas Preudhomme wrote:
>
>
> On 14/06/17 18:03, Richard Earnshaw (lists) wrote:
>> On 14/06/17 17:49, Thomas Preudhomme wrote:
>>> Hi,
>>>
>>> Testcase gcc.target/arm/its.c was added as part of a patch [1] to limit
>>> IT blocks to 2 instructions maximum. However, the patch w
On 15/06/17 09:16, Ramana Radhakrishnan wrote:
> crtl->is_leaf has a comment above it referring to "Local Register
> Allocation". However this is set by IRA and not LRA since the meaning of
> Local Register Allocator in GCC has changed quite drastically since 1999
> when this comment was introduced
Hello,
I apologize for absurdly long time to check the patch. I misread the testcase
originally and got confused. Now it makes sense to me.
It does not make sense to keep the alias in symtab when we know that it
was prevailed by external definition. So lto-symtab should turn it into
normal exter
> >> * gcc.target/arm/sdiv_costs_1.c:
> >> Require arm_arch_v8a_ok and add march option.
> >>
>
> Shouldn't you use
> add_options_for_arm_arch_v8a instead?
Done, committed as r249214.
I don't quite understand the difference, but this test suite does quite
counter intuitive things
I happened to notice that recently a couple of testcases have sneaked in
that are restricted to x86_64-*-* targets only. This is always wrong:
it should be i?86-*-* and x86_64-*-* alike, eventually restricing the
test to ilp32 or lp64. There were also instances of i?86-*-* only,
which I've handle
On 10/06/17 04:38 +0300, Ville Voutilainen wrote:
- static void __check(...);
+ template
+struct __is_convertible_to_basic_istream
+: __is_convertible_to_basic_istream_impl<_Tp>
+{
public:
- using istream_type =
- decltype(__check(declval::type*>()));
- using
On 13/06/17 21:51 +0200, François Dumont wrote:
On 12/05/2017 13:03, Jonathan Wakely wrote:
A much simpler (but equivalent) change would be:
--- a/libstdc++-v3/src/c++98/tree.cc
+++ b/libstdc++-v3/src/c++98/tree.cc
@@ -153,6 +153,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
/* Static keyword was miss
On 13/06/17 22:36 +0200, François Dumont wrote:
On 01/06/2017 15:34, Jonathan Wakely wrote:
I would expect the constructor to look like this:
_Bvector_impl()
_GLIBCXX_NOEXCEPT_IF( noexcept(_Bit_alloc_type()) )
: _Bit_alloc_type()
{ }
What happens when you do that?
On 15/06/17 11:13 +0200, Rainer Orth wrote:
I've recently been reminded that the pthread tests in libstdc++ still
use insanely long lists of targets to control where they are run. I'd
several times promised to do something about that, and here's the patch
that finally does.
The patch is mostly
On 15/06/17 12:51 +0200, Rainer Orth wrote:
I happened to notice that recently a couple of testcases have sneaked in
that are restricted to x86_64-*-* targets only. This is always wrong:
it should be i?86-*-* and x86_64-*-* alike, eventually restricing the
test to ilp32 or lp64. There were also
On 06/14/2017 01:24 PM, Olivier Hainque wrote:
I'm happy to try the patch.
That would bring useful extra datapoints, Thanks!
I now seem unable to trigger the race with an unpatched source. Sorry
--
Nathan Sidwell
Hi all,
the attached patch fixes a runtime memory leak with procedure-pointer
components (PPCs). gfortran correctly deallocates scalar allocatable
function results (also for procedure pointers), but fails to do so for
PPCs, which is cured by my patch.
[Note: Since gfortran translates any type-bou
On 06/12/2017 10:29 AM, Jan Hubicka wrote:
I wonder if there are any other obvious candidates for branch prediction
in C++ FE?
Not that I can think of.
I know others have mentioned exit, and you've commented. It does seem
to me to be not particularly hot[1], and optimizing speed of exit is
> On 15 Jun 2017, at 14:03, Nathan Sidwell wrote:
>
> On 06/14/2017 01:24 PM, Olivier Hainque wrote:
>
>>> I'm happy to try the patch.
>> That would bring useful extra datapoints, Thanks!
>
> I now seem unable to trigger the race with an unpatched source. Sorry
No pb. Thanks for trying.
We w
>
> This patch is pretty huge, are there any opportunities to further split it to
> aid
> review?
Unfortunately because I'm also changing some constraints it introduced a bit of
a dependency cycle.
If I were to break it up more, the individual patches won't work on their own
anymore.
Hi Richard,
> > +rtx tmp = gen_reg_rtx (SImode);
> > +aarch64_expand_mov_immediate (tmp, gen_int_mode (ival, SImode));
> > +tmp = simplify_gen_subreg (HImode, tmp, SImode, 0);
>
> This looks wrong for big-endian, and...
>
> > +emit_move_insn (operands[0], gen_lowpart (HFmode, tmp
Hi Janus,
It regtests cleanly on x86_64-linux-gnu. Ok for trunk?
OK.
Thanks for the patch!
Regards
Thomas
Hi Jozef,
> Sorry, didn't mention in that last post that I don't have write access,
> could someone please apply this for me.
Applied. Sorry about the delay (again).
Cheers
Nick
Michael Collison writes:
> +(define_insn_and_split "*aarch64_reg_3_neg_mask2"
> + [(set (match_operand:GPI 0 "register_operand" "=r")
> + (SHIFT:GPI
> + (match_operand:GPI 1 "register_operand" "r")
> + (match_operator 4 "subreg_lowpart_operator"
> + [(neg:SI (and:SI (match_o
Ping for this Ada patch/question.
Richard Sandiford writes:
> Richard Biener writes:
How does this look? Changes since v1:
- Added access_fn_component_p to check for valid access function
components.
- Added access_fn_components_comparable_p instead of using
Hi,
the transformation done to TARGET_MEM_REF in maybe_canonicalize_mem_ref_addr
is exactly the same as one of those done in maybe_fold_tmr, the latter is
better written and the former function calls the latter, so this patch changes
maybe_canonicalize_mem_ref_addr to avoid touching TARGET_MEM_
Wilco Dijkstra wrote:
> James Greenhalgh wrote:
>
> > I note this is still marked as an RFC, are you now proposing it as a
> > patch to be merged to trunk?
>
> Absolutely. It was marked as an RFC to get some comments - I thought it
> may be controversial to separate the frame pointer and frame cha
Hi Richard,
> > > +rtx tmp = gen_reg_rtx (SImode);
> > > +aarch64_expand_mov_immediate (tmp, gen_int_mode (ival,
> SImode));
> > > +tmp = simplify_gen_subreg (HImode, tmp, SImode, 0);
> >
> > This looks wrong for big-endian, and...
> >
> > > +emit_move_insn (operands[0], gen_lowpa
On 14/06/17 15:07, James Greenhalgh wrote:
> On Tue, Jun 13, 2017 at 03:00:28PM +0100, Wilco Dijkstra wrote:
>>
>> ping
>
> I've been avoiding reviewing this patch as Richard was the last to comment
> on it, and I wasn't sure that his comments had been resolved to his
> satisfaction. The conversat
Ping.
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00383.html
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01186.html
Thanks, David
On 06/09/2017 07:31 AM, H.J. Lu wrote:
On Thu, Jun 8, 2017 at 12:13 PM, Martin Sebor wrote:
On 06/08/2017 11:00 AM, H.J. Lu wrote:
On Wed, Jun 7, 2017 at 6:30 AM, H.J. Lu wrote:
On Tue, Jun 6, 2017 at 5:11 PM, Martin Sebor wrote:
On 06/06/2017 04:57 PM, H.J. Lu wrote:
On Tue, Jun 6,
On 15/06/17 15:12, Wilco Dijkstra wrote:
This results in smaller code and unwind info.
I have done a quick test on your updated patch through building latest linux
kernel.
Dwarf frame size improved (~ 5% smaller) as using sp to address locals doesn't
need to update CFA register etc.
Though th
On Thu, Jun 15, 2017 at 8:38 AM, Martin Sebor wrote:
>>
>> Where do we go from here?
>
>
> Other than the C and C++ maintainers needing to approve the patch
> I can't think of anything else.
Hi Joseph, Jason,
The complete patch is at
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00541.html
Is
On Mon, Jun 12, 2017 at 11:40:17AM -0700, Carl E. Love wrote:
> OK, so sounds like I should stick to the general wa register constraint.
> The third field of the define_expand I have what I believe is called the
> "condition string" as "TARGET_VSX". Is that the appropriate condition
> string? I s
Forgetting the patch: check!
Sending it later as a reply to the wrong message: check!
Hopefully I won't check a second time any of those.
Best regards,
Thomas
On 14/06/17 13:30, Thomas Preudhomme wrote:
Hi,
dg-cmp-results.sh contrib script is written to work with sum file for
a single tool o
Hi,
Conditions checked for ARM targets in vector-related effective targets
are inconsistent:
* sometimes arm*-*-* is checked
* sometimes Neon is checked
* sometimes arm_neon_ok and sometimes arm_neon is used for neon check
* sometimes check_effective_target_* is used, sometimes is-effective-targ
On 14/06/17 10:35, Prakhar Bahuguna wrote:
> The ARM ACLE defines the __ARM_FEATURE_COPROC macro which indicates which
> coprocessor intrinsics are available for the target. If __ARM_FEATURE_COPROC
> is
> undefined, the target does not support coprocessor intrinsics. The feature
> levels are defin
On 06/12/2017 03:36 PM, Jason Merrill wrote:
On 06/08/2017 01:25 PM, Martin Sebor wrote:
+ if (TREE_CHAIN (DECL_ARGUMENTS (f)))
+{
+ /* Skip constructors that aren't copy or move ctors. */
+ if (!copy_fn_p (f))
+continue;
+
+ cpy_or_move_ctor_p = true;
+}
+
Richard Earnshaw wrote:
> Yes, I still believe that this is a bug in the way we've documented the
> -mcmodel=tiny and -mcmodel=small options.
In what way could this possibly be a documentation bug? It's not at all related
to the size of a binary. There is no limit to the offset you can apply to a
Attached is a documentation-only change to add comments explaining
the C++ cp_operator_id and cp_assignment_operator_id macros.
Martin
gcc/cp/ChangeLog:
* cp-tree.h (cp_operator_id, cp_assignment_operator_id): Document.
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index da45d95..234441b 10
On Mon, Jun 12, 2017 at 01:01:36PM -0700, Carl E. Love wrote:
> * config/rs6000/rs6000-c.c: Add definitions for the vec_float,
> vec_float2, vec_floato, vec_floate built-ins.
> * config/rs6000/vsx.md: Add RTL code for instructions vsx_xvcvsxws
> vsx_xvcvuxwsp, float2, floato
On Thu, 15 Jun 2017, H.J. Lu wrote:
> On Thu, Jun 15, 2017 at 8:38 AM, Martin Sebor wrote:
> >>
> >> Where do we go from here?
> >
> >
> > Other than the C and C++ maintainers needing to approve the patch
> > I can't think of anything else.
>
> Hi Joseph, Jason,
>
> The complete patch is at
>
On Thu, Jun 15, 2017 at 6:08 AM, Yuri Gribov wrote:
> Hi all,
>
> This patch fixes regression at bootstrap-O3.
>
> Local x64 bootstrap-O3 has completed w/o errors. I didn't run regtests
> (I think it's not needed, given that new code can now run in fewer
> cases than before).
>
> Ok to commit? (if
On 15/06/17 17:55, Wilco Dijkstra wrote:
> Richard Earnshaw wrote:
>> Yes, I still believe that this is a bug in the way we've documented the
>> -mcmodel=tiny and -mcmodel=small options.
>
> In what way could this possibly be a documentation bug? It's not at all
> related
> to the size of a binary
Jiong Wang wrote:
test.c
===
struct K {
int a;
int b;
int c;
int d;
char e;
short f;
long g;
float h;
double i;
};
void foo (int, struct K *);
void test (int i)
{
struct K k = {
.a = 5,
.b = 0,
.c = i,
};
foo (5, &k);
}
There are 2 separate latent bugs here, bo
Richard Earnshaw wrote:
>
> You can write it, but it's meaningless by the C standard. You can't
> take the address beyond one after the size of the object, so anything
> more than &a+1 has no meaning.
No it's perfectly valid and such out-of-range cases occur thousands of
times when building any n
Hi Will,
On Tue, Jun 13, 2017 at 02:44:45PM -0500, Will Schmidt wrote:
> I sniff-tested the latest changes on Power8, with good results. Full
> regtest running. OK for trunk?
This looks good to me, if Richard is happy with it now. Some very minor
things and it is good to go:
> 2017-06-1
On 15/06/17 18:51, Wilco Dijkstra wrote:
> Richard Earnshaw wrote:
>>
>> You can write it, but it's meaningless by the C standard. You can't
>> take the address beyond one after the size of the object, so anything
>> more than &a+1 has no meaning.
>
> No it's perfectly valid and such out-of-range
Richard Earnshaw wrote:
C11: Summary of undefined behaviours.
— Addition or subtraction of a pointer into, or just beyond, an array
object and an
integer type produces a result that does not point into, or just beyond,
the same array
object (6.5.6).
That's totally irrelevant given the addition i
On 15/06/17 19:18, Wilco Dijkstra wrote:
> Richard Earnshaw wrote:
>
> C11: Summary of undefined behaviours.
>
> — Addition or subtraction of a pointer into, or just beyond, an array
> object and an
> integer type produces a result that does not point into, or just beyond,
> the same array
> obje
Richard Earnshaw wrote:
> No it's not. The optimizer doesn't create totally random bases. If the
> code + data is less than 1M in size, then any offsets it does create
> will fit within the size of the relocations selected by the compiler.
No that's completely false. There is no way you can guar
On Thu, 15 Jun 2017, Wilco Dijkstra wrote:
> Richard Earnshaw wrote:
> > No it's not. The optimizer doesn't create totally random bases. If the
> > code + data is less than 1M in size, then any offsets it does create
> > will fit within the size of the relocations selected by the compiler.
>
>
Hi Ian,
> I've committed this patch to the top level Makefile.def so that `make
> check-go` will run `make check-gotools`. Bootstrapped and ran Go
> testsuite on x86_64-pc-linux-gnu. Committed to mainline.
>
> This patch may cause new test failures on other systems. Please let
> me know about t
2017-06-15 15:33 GMT+02:00 Thomas Koenig :
> Hi Janus,
>
>> It regtests cleanly on x86_64-linux-gnu. Ok for trunk?
>
>
> OK.
>
> Thanks for the patch!
Thanks, Thomas! Committed as r249227.
Cheers,
Janus
On Thu, Jun 15, 2017 at 12:57 PM, Martin Sebor wrote:
> Attached is a documentation-only change to add comments explaining
> the C++ cp_operator_id and cp_assignment_operator_id macros.
Hmm, I'd say that these macros return the identifier used internally
to represent "operator OP" and "operator O
On Thu, Jun 15, 2017 at 12:26 PM, Martin Sebor wrote:
> On 06/12/2017 03:36 PM, Jason Merrill wrote:
>>
>> On 06/08/2017 01:25 PM, Martin Sebor wrote:
>>>
>>> + if (TREE_CHAIN (DECL_ARGUMENTS (f)))
>>> +{
>>> + /* Skip constructors that aren't copy or move ctors. */
>>> + if (!
On 06/15/2017 03:24 PM, Jason Merrill wrote:
On Thu, Jun 15, 2017 at 12:57 PM, Martin Sebor wrote:
Attached is a documentation-only change to add comments explaining
the C++ cp_operator_id and cp_assignment_operator_id macros.
Hmm, I'd say that these macros return the identifier used internal
I thought the patch was fine as I posted. I had an optimization I thought
about (optimizing for inserting 0.0f) and I noticed some problems with it.
However, even in backing out the change, there are some problems. So, I will
hopefully reissue the patch tomorrow.
--
Michael Meissner, IBM
IBM, M
On 06/14/2017 11:24 AM, Jason Merrill wrote:
On Tue, Jun 13, 2017 at 8:32 AM, Martin Liška wrote:
(canonize_attr_name): New function.
I think this should be "canonicalize"; "canonize" means something else.
Right. I was about to make the same observation but then grepped
GCC sources
On Thu, Jun 15, 2017 at 2:00 PM, Rainer Orth
wrote:
>
>> I've committed this patch to the top level Makefile.def so that `make
>> check-go` will run `make check-gotools`. Bootstrapped and ran Go
>> testsuite on x86_64-pc-linux-gnu. Committed to mainline.
>>
>> This patch may cause new test failu
On Thu, Jun 15, 2017 at 07:39:39PM -0400, Michael Meissner wrote:
> I thought the patch was fine as I posted. I had an optimization I thought
> about (optimizing for inserting 0.0f) and I noticed some problems with it.
> However, even in backing out the change, there are some problems. So, I will
Hi,
This test hangs on avx512er, maybe that's why:
> According to POSIX, the behavior of a process is undefined after it ignores a
> SIGFPE, SIGILL, or SIGSEGV signal that was not generated by kill(2) or
> raise(3).
And volatile make it work even without a patch(r1 and r2 are not combined then)
61 matches
Mail list logo
