> On 07/20/16 20:08, Richard Biener wrote:
> > On July 20, 2016 6:54:48 PM GMT+02:00, Bernd Edlinger
> > wrote:
> >>
> >> Yes. That is another interesting observation. I think, originally this
> >> flag was introduced by Jan Hubicka, and should mean, "it may be alloca
> >> or a weak alias to all
On 21/07/16 00:18 -0400, Ed Smith-Rowland wrote:
This patch defines
operator""zu(unsigned long long __n)
for size_t literals.
for (auto k = 0zul; k < v.size(); ++k)
...
Testing on x86-64-linux is finishing but I'm past these tests.
OK?
P0330 isn't in C++17. In Oulu LEWG voted to forwa
Here we were returning OK from cp_parser_lambda_declarator_opt even
though we had encountered parse errors, and so parsing the inner
lambda aborted due to seeing an error_mark_node expression-statement
without ever having emitted any errors.
Fixed by clearing OK if there were parse errors.
Tested
Here one operand of the comparison had been reduced to an INTEGER_CST
and the other was still a PTRMEM_CST. We should deal with that
situation by reducing the PTRMEM_CST.
Tested x86_64-pc-linux-gnu, applying to trunk and 6.
commit 984c524f8a302059a1f71f84935dcae5f9914c7f
Author: Jason Merrill
Da
The fix for 65168 didn't check c_inhibit_evaluation_warnings, which
means getting warnings about comparing the address of a reference to
NULL in places where we aren't actually interested in the value. This
patch corrects that, but this lead to some regressions because
cp_truthvalue_conversion was
The problem here was that the code that tries to prevent the -Waddress
warning used cp_fully_fold, and later code used maybe_constant_value,
and the latter simplified the operand more so that it exposed the
ADDR_EXPR to the -Waddress warning. Fixed by calling
maybe_constant_value from cp_fully_fol
OK.
On Wed, Jul 20, 2016 at 5:05 PM, Jakub Jelinek wrote:
> Hi!
>
> In PR69315, we've recently allowed recursive genericization, unfortunately
> the bc_label handling isn't prepared for that, we ICE if we cp_genericize
> some function (usually newly instantiated method) while inside of some loop
This patch defines
operator""zu(unsigned long long __n)
for size_t literals.
for (auto k = 0zul; k < v.size(); ++k)
...
Testing on x86-64-linux is finishing but I'm past these tests.
OK?
Ed
2016-07-21 Edward Smith-Rowland <3dw...@verizon.net>
Implement C++17 P0330 size_t
On 7/12/16 8:48 AM, Alan Modra wrote:
On Tue, Jul 12, 2016 at 02:02:43PM +0200, Ulrich Weigand wrote:
The second time around, get_secondary_mem should reuse the
same stack slot it already allocated, and the elimination
offsets should already be set to accommodate that stack slot,
which means the
On Wed, 2016-07-20 at 16:16 -0400, Jason Merrill wrote:
> On Thu, Jun 30, 2016 at 1:49 PM, Jason Merrill
> wrote:
> > This needs a template testcase.
>
> Did you get this reply before? It bounced from the mailing list, but
> I thought you would have gotten it directly.
I did; sorry for not resp
On 07/06/2016 08:32 AM, Jan Beulich wrote:
While it always seemed wrong to me that there's no way to avoid the
default "flags" and "fpsr" clobbers, the regression the fix for
PR/60663 introduced (see PR/63637) makes it even more desirable to have
such a mechanism: This way, at least asm()s with a
On 07/21/16 00:19, Bernd Edlinger wrote:
> On 07/21/16 00:00, Jakub Jelinek wrote:
>> On Wed, Jul 20, 2016 at 09:50:03PM +, Bernd Edlinger wrote:
>>> But the built-in alloca is still recognized because the builtin
>>> does have ECF_MAY_BE_ALLOCA and ECF_MALLOC.
>>
>> But __builtin_alloca_with
On 07/21/16 00:00, Jakub Jelinek wrote:
> On Wed, Jul 20, 2016 at 09:50:03PM +, Bernd Edlinger wrote:
>> But the built-in alloca is still recognized because the builtin
>> does have ECF_MAY_BE_ALLOCA and ECF_MALLOC.
>
> But __builtin_alloca_with_align likely doesn't have ECF_MALLOC set (even
>
The new canada hotel is looking for over 100 foreign workers.
Contact the Canadian Administrator by e-mail: forapplica...@yahoo.ca, if it
interests you.
Ray
On 20 July 2016 at 23:07, Prathamesh Kulkarni
wrote:
> On 20 July 2016 at 16:35, Richard Biener wrote:
>> On Wed, 20 Jul 2016, Prathamesh Kulkarni wrote:
>>
>>> On 8 July 2016 at 12:29, Richard Biener wrote:
>>> > On Fri, 8 Jul 2016, Richard Biener wrote:
>>> >
>>> >> On Fri, 8 Jul 2016, Pratham
On 20 July 2016 at 16:35, Richard Biener wrote:
> On Wed, 20 Jul 2016, Prathamesh Kulkarni wrote:
>
>> On 8 July 2016 at 12:29, Richard Biener wrote:
>> > On Fri, 8 Jul 2016, Richard Biener wrote:
>> >
>> >> On Fri, 8 Jul 2016, Prathamesh Kulkarni wrote:
>> >>
>> >> > Hi Richard,
>> >> > For the
On Wed, Jul 20, 2016 at 09:50:03PM +, Bernd Edlinger wrote:
> But the built-in alloca is still recognized because the builtin
> does have ECF_MAY_BE_ALLOCA and ECF_MALLOC.
But __builtin_alloca_with_align likely doesn't have ECF_MALLOC set (even
when it should).
Jakub
On 07/20/2016 11:16 PM, Uros Bizjak wrote:
As suggested by Jakub.
2016-07-20 Uros Bizjak
* hwint.h (HOST_WIDE_INT_0): New define.
(HOST_WIDE_INT_0U): Ditto.
* double-int.c: Use HOST_WIDE_INT_0 instead of (HOST_WIDE_INT) 0.
* dse.c: Use HOST_WIDE_INT_0U instead of (unsigned HO
On 06/29/2016 05:54 AM, Richard Biener wrote:
Currently as-base classes lack DECL_BIT_FIELD_REPRESENTATIVEs which
means RTL expansion doesn't honor the C++ memory model for bitfields
in them thus for the following testcase
struct B {
B() {}
int x;
int a : 6;
int b : 6;
int c
On 07/20/16 20:08, Richard Biener wrote:
> On July 20, 2016 6:54:48 PM GMT+02:00, Bernd Edlinger
> wrote:
>>
>> But I think that alloca just should not be recognized by name any
>> more.
>
> It was introduced to mark calls that should not be duplicated by inlining or
> unrolling to avoid increas
On 06/28/2016 12:18 AM, Bin Cheng wrote:
Hi,
This patch improves vectorizer in order to handle possible infinite loops by
versioning. Its changes fall in three categories.
A) Changes in vect_get_loop_niters. AT the moment, it computes niter using
number_of_executions_latch, in this way the as
As suggested by Jakub.
2016-07-20 Uros Bizjak
* hwint.h (HOST_WIDE_INT_0): New define.
(HOST_WIDE_INT_0U): Ditto.
* double-int.c: Use HOST_WIDE_INT_0 instead of (HOST_WIDE_INT) 0.
* dse.c: Use HOST_WIDE_INT_0U instead of (unsigned HOST_WIDE_INT) 0.
* simplify-rtx.c: Ditto.
Hi!
In PR69315, we've recently allowed recursive genericization, unfortunately
the bc_label handling isn't prepared for that, we ICE if we cp_genericize
some function (usually newly instantiated method) while inside of some loop
in the outer function.
Fixed thusly, bootstrapped/regtested on x86_6
On 07/20/2016 08:04 AM, Szabolcs Nagy wrote:
Fix target library tests when gcc is built using --with-build-sysroot.
The dejagnu find_gcc function cannot handle if CC needs extra flags
like --sysroot. So for testing target libraries use the same CC that
was used for building the target libs. This
On Thu, Jun 30, 2016 at 1:49 PM, Jason Merrill wrote:
> This needs a template testcase.
Did you get this reply before? It bounced from the mailing list, but
I thought you would have gotten it directly.
Jason
On 06/22/2016 08:52 PM, David Malcolm wrote:
PR c/71613 identifies a problem where we fail to report this enum:
enum { e1 = LLONG_MIN };
with -pedantic, due to LLONG_MIN being inside a system header.
This patch updates the C and C++ frontends to use the location of the
name as the primary lo
On 06/22/2016 02:48 PM, Bernd Edlinger wrote:
On 06/22/16 21:51, Jeff Law wrote:
On 06/19/2016 07:25 AM, Bernd Edlinger wrote:
Hi,
ping...
As this discussion did not make any progress, I just attached
the latest version of my patch with the the changes that
Vladimir proposed.
Boot-strapped a
> Very few targets continue to use SJLJ eh (perhaps just cygwin/mingw).
> *But* I think the Ada front-end explicitly uses SJLJ EH, so if you want
> to get some smoke testing, the Ada testsuite is probably the place to go.
Right, the Ada front-end uses an EH scheme directly based on __builtin_setjm
On 20 July 2016 at 19:21, ayush goel wrote:
> Hey,
> As a first step of my GSOC project
> (https://gcc.gnu.org/wiki/replacelibibertywithgnulib) I have imported
> the gnulib library inside the gcc tree. I have created gnulib as a top
> level directory which contains the necessary scripts to import
On Fri, 2016-07-08 at 17:49 -0400, David Malcolm wrote:
[...]
> Also, this patch currently makes the assumption (in charset.c)
> that there's a 1:1 correspondence between bytes in the source
> character set and bytes in the execution character set. This can
> be the case if both are, say, UTF-8,
e:
=== acats Summary ===
# of expected passes2320
# of unexpected failures0
Native configuration is x86_64-pc-linux-gnu
=== gnat tests ===
Running target unix
FAIL: gnat.dg/vect3.adb scan-tree-dump-times vect "vectorized 1 loops"
Le 20/07/2016 à 11:39, Andre Vehreschild a écrit :
Hi Mikael,
+ if(st == ST_FAIL_IMAGE)
+new_st.op = EXEC_FAIL_IMAGE;
+ else
+gcc_unreachable();
You can use
gcc_assert (st == ST_FAIL_IMAGE);
foo...;
instead of
if (st == ST_FAIL_IMAGE)
foo...;
On 07/20/2016 10:30 AM, Bernd Edlinger wrote:
On 07/20/16 18:15, Jeff Law wrote:
On 07/20/2016 05:53 AM, Richard Biener wrote:
Is it OK after boot-strap and regression-testing?
I think the __builtin_setjmp change is wrong - __builtin_setjmp is
_not_ 'setjmp' it is part of the GCC internal mac
On 07/20/2016 10:54 AM, Bernd Edlinger wrote:
Yes. That is another interesting observation. I think, originally this
flag was introduced by Jan Hubicka, and should mean, "it may be alloca
or a weak alias to alloca or maybe even something different".
But some of the later optimizations use it i
On Wed, Jul 20, 2016 at 2:15 PM, Martin Sebor wrote:
> On 07/20/2016 07:52 AM, Jason Merrill wrote:
>>
>> On Mon, Jul 18, 2016 at 6:15 PM, Martin Sebor wrote:
>>>
>>> On 07/18/2016 11:51 AM, Jason Merrill wrote:
On 07/06/2016 06:20 PM, Martin Sebor wrote:
>
>
> @@ -2911
On 07/20/2016 12:30 PM, Bernd Edlinger wrote:
On 07/20/16 20:08, Richard Biener wrote:
On July 20, 2016 6:54:48 PM GMT+02:00, Bernd Edlinger
wrote:
Yes. That is another interesting observation. I think, originally this
flag was introduced by Jan Hubicka, and should mean, "it may be alloca
o
On 24/05/16 17:02 +0100, Jonathan Wakely wrote:
* include/bits/stl_queue.h (priority_queue::value_compare): Define.
This is only Tentatively Ready but I don't think there's any harm in
making the change now. Libc++ have been shipping this for years,
without realising it wasn't actually i
* include/std/atomic (atomic_int8_t, atomic_uint8_t, atomic_int16_t)
(atomic_uint16_t, atomic_int32_t, atomic_uint32_t, atomic_int64_t)
(atomic_uint64_t): Define (LWG 2441).
* testsuite/29_atomics/headers/atomic/std_c++0x_neg.cc: Remove empty
lines.
With the last change the not-aligned symbol ref markers are always set
for modes with size zero. This is wrong since for larl the size of
the access does not matter. This patch removes that check entirely
from s390_encode_section_info. Modes with a size of 0 get rejected in
s390_check_symref_ali
On 07/20/16 20:08, Richard Biener wrote:
> On July 20, 2016 6:54:48 PM GMT+02:00, Bernd Edlinger
> wrote:
>>
>> Yes. That is another interesting observation. I think, originally this
>> flag was introduced by Jan Hubicka, and should mean, "it may be alloca
>> or a weak alias to alloca or maybe e
* include/std/istream (operator>>(basic_istream&&, _Tp&)): Adjust
to use perfect forwarding (LWG 2328).
* testsuite/27_io/rvalue_streams.cc: Test perfect forwarding.
* doc/xml/manual/intro.xml: Document DR 2328 status.
Teted x86_64-linux, committed to trunk.
commit
Hey,
As a first step of my GSOC project
(https://gcc.gnu.org/wiki/replacelibibertywithgnulib) I have imported
the gnulib library inside the gcc tree. I have created gnulib as a top
level directory which contains the necessary scripts to import the
modules. It also contains the necessary Makefile.in
On 07/20/2016 07:52 AM, Jason Merrill wrote:
On Mon, Jul 18, 2016 at 6:15 PM, Martin Sebor wrote:
On 07/18/2016 11:51 AM, Jason Merrill wrote:
On 07/06/2016 06:20 PM, Martin Sebor wrote:
@@ -2911,6 +2923,14 @@ cxx_eval_indirect_ref (const constexpr_ctx
*ctx, tree t,
if (*non_constan
On July 20, 2016 6:54:48 PM GMT+02:00, Bernd Edlinger
wrote:
>On 07/20/16 18:20, Jeff Law wrote:
>> On 07/20/2016 09:41 AM, Bernd Edlinger wrote:
>>> On 07/20/16 12:44, Richard Biener wrote:
On Tue, 19 Jul 2016, Bernd Edlinger wrote:
> Hi!
>
> As discussed at
>https://gcc.gn
On 07/20/2016 10:58 AM, Bin Cheng wrote:
Hi,
After patch @238301, issue reported in PR65206 is also exposed by case
gcc.dg/vect/vect-mask-store-move-1.c. This patch xfail the case for the moment.
Test result checked, is it OK?
Thanks,
bin
gcc/testsuite/ChangeLog
2016-07-14 Bin Cheng
On Jul 19, 2016, at 10:37 PM, Senthil Kumar Selvaraj
wrote:
> The patch fixes a couple of testsuite failures that show up for the
> avr target because it has different sizes for longs and pointers (4
> bytes versus 2), by explicitly disabling the warning for avr.
>
> Does this make sense?
I
On 07/20/2016 01:55 PM, Dominik Vogt wrote:
> The attached patch rewrites the pr67443.c testcase in a different
> way so that the test still works with the changed allocation of
> globals pinned to registers. The test ist hopefully more robust
> now. The test ist hopefully more robust now. Teste
On 07/19/2016 11:40 AM, Dominik Vogt wrote:
> The attached patch XFAILs some of the "insv" testcases as
> discussed internally. Tested on s390x biarch and s390.
Applied. Thanks!
-Andreas-
This patch renames the configure switches to be explicit that they are for the
PowerPC, and that they are temporary. I would hope by the time GCC 7 exits
stage1 that these switches will be removed, but having them now will allow us
to move to LRA and __float128 in an orderly fashion.
I built a bo
On 07/07/16 17:17, Jiong Wang wrote:
This patch add ARMv8.2-A FP16 two operands scalar intrinsics.
The updated patch resolve the conflict with
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00309.html
The change is to let aarch64_emit_approx_div return false for HFmode.
gcc/
2016-07-20 Ji
On 07/07/16 17:17, Jiong Wang wrote:
This patch add ARMv8.2-A FP16 one operand scalar intrinsics
Scalar intrinsics are kept in arm_fp16.h instead of arm_neon.h.
The updated patch resolve the conflict with
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00308.html
The change is to let aarch6
On 07/07/16 17:15, Jiong Wang wrote:
This patch add ARMv8.2-A FP16 two operands vector intrinsics.
The updated patch resolve the conflict with
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00309.html
The change is to let aarch64_emit_approx_div return false for
V4HFmode and V8HFmode.
gcc/
On 07/07/16 17:14, Jiong Wang wrote:
This patch add ARMv8.2-A FP16 one operand vector intrinsics.
We introduced new mode iterators to cover HF modes, qualified patterns
which was using old mode iterators are switched to new ones.
We can't simply extend old iterator like VDQF to conver HF modes,
Hi,
After patch @238301, issue reported in PR65206 is also exposed by case
gcc.dg/vect/vect-mask-store-move-1.c. This patch xfail the case for the moment.
Test result checked, is it OK?
Thanks,
bin
gcc/testsuite/ChangeLog
2016-07-14 Bin Cheng
* gcc.dg/vect/vect-mask-store-move-1.c: X
On 07/20/16 18:20, Jeff Law wrote:
> On 07/20/2016 09:41 AM, Bernd Edlinger wrote:
>> On 07/20/16 12:44, Richard Biener wrote:
>>> On Tue, 19 Jul 2016, Bernd Edlinger wrote:
>>>
Hi!
As discussed at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876,
we have a _very_ old hack in
Hi,
This patch cleans up function number_of_iterations_lt_to_ne mainly by removing
computation of may_be_zero. The computation is unnecessary and may_be_zero in
this case must be true. Specifically, DELTA is integer constant and iv0.base <
iv1.base bounds to be true because the false case is h
On Wed, Jul 20, 2016 at 01:41:39PM +0200, Bernd Schmidt wrote:
> On 07/20/2016 11:51 AM, James Greenhalgh wrote:
>
> >
> >2016-07-20 James Greenhalgh
> >
> > * target.def (max_noce_ifcvt_seq_cost): New.
> > * doc/tm.texi.in (TARGET_MAX_NOCE_IFCVT_SEQ_COST): Document it.
> > * doc/tm
On Wed, Jul 06, 2016 at 04:18:49PM +0200, Roger Pau Monne wrote:
> At the moment the -m16 option only passes the "--32" parameter to the
> assembler on glibc OSes, while on other OSes the assembler is called without
> any specific flag. This is wrong and causes the assembler to fail. Fix it
> by ad
On 07/20/16 18:15, Jeff Law wrote:
> On 07/20/2016 05:53 AM, Richard Biener wrote:
>>> Is it OK after boot-strap and regression-testing?
>>
>> I think the __builtin_setjmp change is wrong - __builtin_setjmp is
>> _not_ 'setjmp' it is part of the GCC internal machinery (using setjmp
>> and longjmp i
On 07/20/2016 06:09 PM, Jeff Law wrote:
So I'm going to let Richi run with the review on this one since the two
of you are already iterating. But I did have one comment on the
placement of the pass.
I believe one of the key things to consider for whether or not something
like this belongs in th
On 07/20/2016 08:37 AM, Ilya Enkovich wrote:
Here is an updated version.
Thanks,
Ilya
--
gcc/
2016-07-20 Ilya Enkovich
* dbgcnt.def (vect_tail_combine): New.
* params.def (PARAM_VECT_COST_INCREASE_COMBINE_THRESHOLD): New.
* tree-vect-data-refs.c (vect_get_new_ssa_na
On Wed, Jul 20, 2016 at 11:01 AM, Richard Biener
wrote:
> On Tue, Jul 19, 2016 at 6:15 PM, Bin.Cheng wrote:
>> On Tue, Jul 19, 2016 at 1:10 PM, Richard Biener
>> wrote:
>>> On Mon, Jul 18, 2016 at 6:27 PM, Bin Cheng wrote:
Hi,
Scalar evolution needs to prove no-overflow for source var
On 07/20/2016 05:53 AM, Richard Biener wrote:
Is it OK after boot-strap and regression-testing?
I think the __builtin_setjmp change is wrong - __builtin_setjmp is
_not_ 'setjmp' it is part of the GCC internal machinery (using setjmp
and longjmp in the end) for SJLJ exception handing.
Am I corr
On 07/20/2016 05:14 AM, Bernd Schmidt wrote:
On 07/19/2016 01:18 PM, Richard Biener wrote:
On Tue, Jul 19, 2016 at 1:07 PM, Bernd Schmidt
wrote:
On 07/19/2016 12:35 PM, Richard Biener wrote:
I think that start/end_recording_case_labels also merged
adjacent labels via group_case_labels_stmt.
On Wed, Jul 20, 2016 at 3:15 PM, Bernd Schmidt wrote:
>
>
> On 07/20/2016 02:25 PM, Uros Bizjak wrote:
>>
>> 2016-07-19 14:46 GMT+02:00 Uros Bizjak :
>>>
>>> The result of exercises with sed in gcc/ directory.
>>
>>
>> Some more conversions:
>>
>> 2016-07-20 Uros Bizjak
>>
>> * cse.c: Use H
On 07/20/2016 09:35 AM, Richard Biener wrote:
I have reported it as PR71947.
Could you help me point out how to fix this ?
Not record both equivalences. This might break the testcase it was
introduced for (obviously). Which is why I CCed Jeff for his opinion.
It's on my todo list. I'm still
Richard Earnshaw wrote:
> So under what circumstances does it lead to sub-optimal code?
If the cost is incorrect Combine can make the wrong decision, for example
whether to emit a multiply-add or not. I'm not sure whether this still happens
as Kyrill fixed several issues in Combine since this patc
On Wed, 20 Jul 2016, Prathamesh Kulkarni wrote:
> On 8 July 2016 at 12:29, Richard Biener wrote:
> > On Fri, 8 Jul 2016, Richard Biener wrote:
> >
> >> On Fri, 8 Jul 2016, Prathamesh Kulkarni wrote:
> >>
> >> > Hi Richard,
> >> > For the following test-case:
> >> >
> >> > int f(int x, int y)
> >>
On 20/07/16 16:28, Wilco Dijkstra wrote:
> Richard Earnshaw wrote:
>> Both of which look reasonable to me.
>
> Yes the code we generate for these examples is fine, I don't believe this
> example ever went bad. It's just the cost calculation that is incorrect with
> the outer check.
>
> Wilco
>
>
Richard Earnshaw wrote:
> Both of which look reasonable to me.
Yes the code we generate for these examples is fine, I don't believe this
example ever went bad. It's just the cost calculation that is incorrect with
the outer check.
Wilco
On 20/07/16 16:02, Jiong Wang wrote:
> On 20/07/16 15:18, Richard Earnshaw (lists) wrote:
>> On 20/07/16 14:03, Jiong Wang wrote:
>>> Those stack adjustment sequences inside aarch64_expand_prologue/epilogue
>>> are doing exactly what's aarch64_add_constant offered, except they also
>>> need to be a
On Wed, Jul 20, 2016 at 01:23:44PM +0200, Bernd Schmidt wrote:
> >>>But you need the profile to make even reasonably good decisions.
> >>
> >>I'm not worried about making cost decisions: as far as I'm concerned
> >>it's perfectly fine for that. I'm worried about correctness - you can't
> >>validly
On 20/07/16 15:18, Richard Earnshaw (lists) wrote:
On 20/07/16 14:03, Jiong Wang wrote:
Those stack adjustment sequences inside aarch64_expand_prologue/epilogue
are doing exactly what's aarch64_add_constant offered, except they also
need to be aware of dwarf generation.
This patch teach existed
On Wed, Jul 20, 2016 at 10:46 AM, David Malcolm wrote:
> @@ -1407,6 +1407,10 @@ lookup_field_fuzzy_info::fuzzy_lookup_field (tree type)
> The TYPE_FIELDS of TYPENAME_TYPE is its TYPENAME_TYPE_FULLNAME. */
> return;
>
> + /* TYPE_FIELDS is not valid for a TYPE_PACK_EXPANSION. */
> +
On 14 Jul 16:04, Jeff Law wrote:
> On 06/28/2016 06:24 AM, Ilya Enkovich wrote:
>
> >
> >Here is an updated patch version.
> >
> >Thanks,
> >Ilya
> >--
> >gcc/
> >
> >+/* Function vect_gen_loop_masks.
> >+
> >+ Create masks to mask a loop described by LOOP_VINFO. Masks
> >+ are created accord
On 20/07/16 15:13, David Edelsohn wrote:
> On Wed, Jul 20, 2016 at 7:09 AM, Szabolcs Nagy wrote:
>> On 20/07/16 14:45, David Edelsohn wrote:
Musl libc does not support gnu ifunc, so disable it by default.
(not disabled on s390-* since that has no musl support yet.)
>>>
>>> Musl libc now
On 18.07.2016 08:58, Denis Chertykov wrote:
2016-07-15 18:26 GMT+03:00 Georg-Johann Lay :
This patch needs new hook TARGET_ADDR_SPACE_DIAGNOSE_USAGE:
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00839.html
This patch turns attribute progmem into a working feature for AVR_TINY
cores.
It boils
On Wed, Jul 20, 2016 at 10:46:58AM -0400, David Malcolm wrote:
> + /* Skip anticipated decls of builtin functions. */
> + if (TREE_CODE (t) == FUNCTION_DECL)
> + if (DECL_BUILT_IN (t))
> + if (DECL_ANTICIPATED (t))
Just a style comment, wouldn't
if (TREE_CODE (t) == FUNC
On 20/07/16 14:03, Jiong Wang wrote:
> Those stack adjustment sequences inside aarch64_expand_prologue/epilogue
> are doing exactly what's aarch64_add_constant offered, except they also
> need to be aware of dwarf generation.
>
> This patch teach existed aarch64_add_constant about dwarf generation
On Wed, Jul 20, 2016 at 7:09 AM, Szabolcs Nagy wrote:
> On 20/07/16 14:45, David Edelsohn wrote:
>>> Musl libc does not support gnu ifunc, so disable it by default.
>>> (not disabled on s390-* since that has no musl support yet.)
>>
>> Musl libc now supports PPC64. Support for s390 is in progress.
Changes in v2:
- split out the non-C++ parts already approved by Jeff (I've committed
these as r238522).
- updated to mirror the fixes for PR c/71858 Jakub made to the
corresponding C implementation in r238352, skipping anticipated decls
of builtin functions
- rewritten to more closely
On 20/07/16 14:02, Jiong Wang wrote:
> This patch optimize immediate addition sequences generated by
> aarch64_add_constant.
>
> The current addition sequences generated are:
>
> * If immediate fit into unsigned 12bit range, generate single add/sub.
> * Otherwise if it fit into unsigned 2
On Wed, 20 Jul 2016, Bernd Schmidt wrote:
> On 07/19/2016 10:20 AM, Richard Biener wrote:
> > I like it. Improving re-build time in my dev tree is very much
> > welcome, and yes,
> > libbackend build time is a big part of it usually (plus of course cc1
> > link time).
>
> Since that wasn't an en
On 20/07/16 14:45, David Edelsohn wrote:
>> Musl libc does not support gnu ifunc, so disable it by default.
>> (not disabled on s390-* since that has no musl support yet.)
>
> Musl libc now supports PPC64. Support for s390 is in progress.
>
it seemed to me that on ppc64 ifunc is disabled by defa
On 20/07/16 14:02, Jiong Wang wrote:
> Currently aarch64_add_constant is using aarch64_build_constant to move
> an immediate into the destination register.
>
> It has considered the following situations:
>
> * immediate can fit into bitmask pattern that only needs single
> instruction.
>
Fix target library tests when gcc is built using --with-build-sysroot.
The dejagnu find_gcc function cannot handle if CC needs extra flags
like --sysroot. So for testing target libraries use the same CC that
was used for building the target libs. This change assumes the test
is ran from make.
Ano
since gcc can be built with --enable-default-pie, there
is a -no-pie flag to turn off PIE.
gcc cannot be built as PIE (pr 71934), so the gcc build
system has to detect the -no-pie flag to disable PIE.
historically default pie toolchains used the -nopie flag
(e.g. gentoo hardened), those toolchain
On 20/07/16 14:40, Wilco Dijkstra wrote:
> Richard Earnshaw wrote:
>> Why does combine care what the cost is if the instruction isn't valid?
>
> No idea. Combine does lots of odd things that don't make sense to me.
> Unfortunately the costs we give for cases like this need to be accurate or
> the
On Mon, Jul 18, 2016 at 6:15 PM, Martin Sebor wrote:
> On 07/18/2016 11:51 AM, Jason Merrill wrote:
>>
>> On 07/06/2016 06:20 PM, Martin Sebor wrote:
>>>
>>> @@ -2911,6 +2923,14 @@ cxx_eval_indirect_ref (const constexpr_ctx
>>> *ctx, tree t,
>>>if (*non_constant_p)
>>> return t;
>>>
>
Musl libc does not support gnu ifunc, so disable it by default.
(not disabled on s390-* since that has no musl support yet.)
gcc/
2016-07-20 Szabolcs Nagy
* config.gcc (*-*-*musl*): Disable gnu-indirect-function.
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 1f75f17..f3f6e14 10064
> Musl libc does not support gnu ifunc, so disable it by default.
> (not disabled on s390-* since that has no musl support yet.)
Musl libc now supports PPC64. Support for s390 is in progress.
- David
OK.
On Mon, Jul 18, 2016 at 5:14 PM, Jakub Jelinek wrote:
> Hi!
>
> This patch fixes two issues:
> 1) as shown in the first testcase, cp_parser_save_member_function_body
>adds the catch () { ... } tokens into the saved token range
>even when there is no function try block (missing try
Richard Earnshaw wrote:
> Why does combine care what the cost is if the instruction isn't valid?
No idea. Combine does lots of odd things that don't make sense to me.
Unfortunately the costs we give for cases like this need to be accurate or
they negatively affect code quality. The reason for thi
OK.
On Mon, Jul 18, 2016 at 5:07 PM, Jakub Jelinek wrote:
> On Mon, Jul 18, 2016 at 02:42:43PM -0400, Jason Merrill wrote:
>> Ah, I guess we need to check cxx_dialect in cxx_eval_store_expression,
>> not just in potential_constant_expression.
>
> Here is an updated version, bootstrapped/regtested
All function classes listed in gcc/coretypes.h are supported by musl.
Most of the optimizations based on these function classes are not
relevant for standard conform c code, but this is required to get
rid of some test system noise.
gcc/
2016-07-20 Szabolcs Nagy
* config/linux.c (linu
Hi.
Following patch addresses ICE which happens when coverage.c computes checksum
of a function w/o xloc.file. My patch assumes it's a valid state having a
function
w/o xloc.file, which is situation exposed by cilkplus functions.
Patch can bootstrap on ppc64le-redhat-linux and survives regressio
On 19/07/16 10:32 +0100, Jonathan Wakely wrote:
On 18/07/16 12:49 -0400, Jason Merrill wrote:
Perhaps the right answer is to drop support for catching nullptr as a
pointers to member from the language.
Yes, I've been drafting a ballot comment along those lines.
On the CWG reflector Richard S
On 20/07/16 14:08, Wilco Dijkstra wrote:
> Richard Earnshaw wrote:
>> I'm not sure about this, while rtx_cost is called recursively as it
>> walks the RTL, I'd normally expect the outer levels of the recursion to
>> catch the cases where zero-extend is folded into a more complex
>> operation. Hitt
On 07/20/2016 02:25 PM, Uros Bizjak wrote:
2016-07-19 14:46 GMT+02:00 Uros Bizjak :
The result of exercises with sed in gcc/ directory.
Some more conversions:
2016-07-20 Uros Bizjak
* cse.c: Use HOST_WIDE_INT_M1 instead of ~(HOST_WIDE_INT) 0.
* combine.c: Use HOST_WIDE_INT_M1U i
Richard Earnshaw wrote:
> I'm not sure about this, while rtx_cost is called recursively as it
> walks the RTL, I'd normally expect the outer levels of the recursion to
> catch the cases where zero-extend is folded into a more complex
> operation. Hitting a case like this suggests that something is
1 - 100 of 146 matches
Mail list logo
