Hi!
When creating lto debugobj, we copy over just the debug sections,
and from the lack of .note.GNU-stack section then on various targets
the linker implies RWE PT_GNU_STACK segment header.
Fixed by copying over also the .note.GNU-stack section if present.
It is not 100% perfect solution if .not
On 6 October 2017 at 14:51, Ian Lance Taylor wrote:
> On Fri, Oct 6, 2017 at 1:34 AM, Iain Buclaw wrote:
>>
>> Out of curiosity, I did have a look at some of the tops of gofrontend
>> sources this morning. They are all copyright the Go Authors, and are
>> licensed as BSD. So I'm not sure if hav
On Tue, 17 Oct 2017, Jan Hubicka wrote:
> > On Tue, 17 Oct 2017, Jan Hubicka wrote:
> >
> > > Hi,
> > > gether/scatter loads tends to be expensive (at least for x86) while we
> > > now account them
> > > as vector loads/stores which are cheap. This patch adds vectorizer cost
> > > entry for th
On 17/10/17 21:39, Sandra Loosemore wrote:
I think the patch is OK with those nits fixed.
Thanks, for the review. Committed as:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=253842
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone
On Wed, Oct 18, 2017 at 09:24:04AM +0200, Jakub Jelinek wrote:
> When creating lto debugobj, we copy over just the debug sections,
> and from the lack of .note.GNU-stack section then on various targets
> the linker implies RWE PT_GNU_STACK segment header.
>
> Fixed by copying over also the .note.G
On Wed, 18 Oct 2017, Jakub Jelinek wrote:
> Hi!
>
> When creating lto debugobj, we copy over just the debug sections,
> and from the lack of .note.GNU-stack section then on various targets
> the linker implies RWE PT_GNU_STACK segment header.
Uh. But those objects don't even have a .text sectio
On Wed, 18 Oct 2017, Jakub Jelinek wrote:
> On Wed, Oct 18, 2017 at 09:24:04AM +0200, Jakub Jelinek wrote:
> > When creating lto debugobj, we copy over just the debug sections,
> > and from the lack of .note.GNU-stack section then on various targets
> > the linker implies RWE PT_GNU_STACK segment
On Wed, Oct 18, 2017 at 10:15:21AM +0200, Richard Biener wrote:
> On Wed, 18 Oct 2017, Jakub Jelinek wrote:
> > When creating lto debugobj, we copy over just the debug sections,
> > and from the lack of .note.GNU-stack section then on various targets
> > the linker implies RWE PT_GNU_STACK segment
The functions all call foo and therefore need a stack frame what makes
them subject to shrink wrapping. Also all the additional instructions
in the function body makes it fragile wrt instruction scheduling. Just
set a global variable instead to circumvent this.
Committed to mainline.
gcc/testsu
On Wed, Oct 18, 2017 at 10:17:49AM +0200, Richard Biener wrote:
> Works for me but as said, why's the linker even caring about
> .note.GNU-stack in objects that do not contain executable code?
The linker simply collects the notes from all *.o files. One case is
when none of the objects have the n
Dear Jerry,
Thanks. I Committed as revision 253848 a still simpler patch that
achieves the same end. Please see the attached and the ChangeLogs
below.
Regards
Paul
2017-10-18 Paul Thomas
PR fortran/82550
* trans_decl.c (gfc_get_symbol_decl): Procedure symbols that
have the 'used
Hi.
I would like to use this thread to slightly describe differences in GCC and
LLVM.
I compared options support by both and:
UBSAN:
1)
gcc: error: unrecognized argument to -fsanitize= option: ‘nullability-arg’
gcc: error: unrecognized argument to -fsanitize= option: ‘nullability-assign’
gcc: e
On Wed, Oct 18, 2017 at 11:00:30AM +0200, Martin Liška wrote:
> Hi.
>
> I would like to use this thread to slightly describe differences in GCC and
> LLVM.
> I compared options support by both and:
>
> UBSAN:
>
> 1)
> gcc: error: unrecognized argument to -fsanitize= option: ‘nullability-arg’
>
> Preserving the sched state across basic blocks for your case works only if
> the BBs are traversed
> with the fall through edges coming first. Is that the case? We probably
> should have a description
> for s390_last_sched_state stating this.
Committed as attached with an additional comment an
On 10/17/2017 06:14 PM, Mike Stump wrote:
On Oct 16, 2017, at 3:16 AM, Tom de Vries wrote:
I noticed gcc.dg/tree-ssa/ldist-27.c failing for nvptx due to a too large stack
size.
OK for trunk?
Hum. There is an existing mechanism (find-grep STACK_SIZE) in the tree to
handle the same issue
> On Oct 17, 2017, at 16:10 , Nathan Sidwell wrote:
>
> On 10/17/2017 05:26 AM, Richard Biener wrote:
>
>> Sorry for not looking at the patch before replying. The patch looks ok
>> but shouldn't LANG_TYPE be also handled by the FE? LANG_TYPE itself
>> is an odd beast if I may say that - it's
On 17 October 2017 at 21:58, Wilco Dijkstra wrote:
> This patch implements some of the optimizations discussed in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71026.
>
> Simplify (C / x > 0.0) into x > 0.0.
>
> If C is negative the comparison is reversed.
>
> Simplify (x * C1) > C2 into x > (C2
On 10/18/2017 11:16 AM, Jakub Jelinek wrote:
> On Wed, Oct 18, 2017 at 11:00:30AM +0200, Martin Liška wrote:
>> Hi.
>>
>> I would like to use this thread to slightly describe differences in GCC and
>> LLVM.
>> I compared options support by both and:
>>
>> UBSAN:
>>
>> 1)
>> gcc: error: unrecognize
On Wed, Oct 18, 2017 at 5:34 AM, Martin Sebor wrote:
> While testing my latest -Wrestrict changes I noticed a number of
> opportunities to improve the -Warray-bounds warning. Attached
> is a patch that implements a solution for the following subset
> of these:
>
> PR tree-optimization/82596 - mis
A volatile asm statement can not be moved (relative to other volatile
asm, etc.), but IRA could do it nevertheless. This patch fixes it.
Testing on powerpc64-linux {-m32,-m64}; okay if it succeeds? Also
for backports?
Segher
2017-10-18 Segher Boessenkool
PR rtl-optimization/82602
On Tue, Oct 17, 2017 at 6:28 PM, Wilco Dijkstra wrote:
> This patch implements some of the optimizations discussed in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71026.
>
> Simplify (C / x > 0.0) into x > 0.0.
>
> If C is negative the comparison is reversed.
>
> Simplify (x * C1) > C2 into x >
Hi,
a rather straightforward issue that we didn't notice so far only because
in all our uses of __is_trivially_constructible either neither type is
dependent or both are (eg, in library uses). The below handles in the
obvious way a possible TREE_LIST - built node by node by
cp_parser_trait_ex
Hi Segher,
the patch looks ok for me.
Just for my understanding:
A memory clobber would also make rtx_moveable_p return false,
thru the following case:
case MEM:
if (type == OP_IN && MEM_READONLY_P (x))
return rtx_moveable_p (&XEXP (x, 0), OP_IN);
return false;
...
c
Hi.
I'm going to install the patch that suppresses -O0 warning:
../../gcc/combine.c: In function ‘rtx_code simplify_compare_const(rtx_code,
machine_mode, rtx, rtx_def**)’:
../../gcc/combine.c:11789:7: warning: this statement may fall through
[-Wimplicit-fallthrough=]
if (const_op > 0)
On Thu, Oct 12, 2017 at 10:51 PM, Eric Botcazou wrote:
> Hi,
>
> this PR reports a couple of problems with the support of the DW_AT_endianity
> attribute associated with the scalar_storage_order source attribute: it does
> not persist through typedefs and it can contaminate native order DIEs.
>
>
On Fri, Oct 13, 2017 at 4:10 PM, Richard Sandiford
wrote:
> Normally we adjust the vector loop so that it iterates:
>
>(original number of scalar iterations - number of peels) / VF
>
> times, enforcing this using an IV that starts at zero and increments
> by one each iteration. However, divid
On Tue, Oct 17, 2017 at 4:28 PM, Bin.Cheng wrote:
> On Mon, Oct 16, 2017 at 5:27 PM, Bin.Cheng wrote:
>> On Mon, Oct 16, 2017 at 5:00 PM, Bin.Cheng wrote:
>>> On Mon, Oct 16, 2017 at 2:56 PM, Bin.Cheng wrote:
On Thu, Oct 12, 2017 at 2:43 PM, Richard Biener
wrote:
> On Thu, Oct 5,
On Tue, Oct 17, 2017 at 4:50 PM, Bin Cheng wrote:
> Hi,
> The patch fixes ICE reported in PR82574. In order to distribute builtin
> partition, we need
> to check that data reference must be executed exactly once per iteration. In
> distribution
> for loop nest, this has to be checked against e
On Tue, Oct 17, 2017 at 6:30 PM, Wilco Dijkstra wrote:
> This patch implements some of the optimizations discussed in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71026.
>
> Canonicalize x / (- y) into (-x) / y.
>
> This moves negates out of the RHS of a division in order to
> allow further simp
On Wed, Oct 18, 2017 at 11:10:48AM +, Bernd Edlinger wrote:
> A memory clobber would also make rtx_moveable_p return false,
> thru the following case:
>
> case MEM:
> if (type == OP_IN && MEM_READONLY_P (x))
> return rtx_moveable_p (&XEXP (x, 0), OP_IN);
> return false;
On Tue, Oct 17, 2017 at 6:32 PM, Wilco Dijkstra wrote:
> This patch implements some of the optimizations discussed in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71026.
>
> Canonicalize x / (C1 * y) into (x * C2) / y.
>
> This moves constant multiplies out of the RHS of a division in order
> to
Le 18/10/2017 à 04:05, Steve Kargl a écrit :
On Tue, Oct 17, 2017 at 06:14:16PM -0700, Jerry DeLisle wrote:
On 10/17/2017 03:36 PM, Thomas Koenig wrote:
Hello world,
this patch fixes a regression with long compile times,
which came about due to our handling of array constructors
at compile tim
On 10/17/2017 06:33 PM, Mike Stump wrote:
On Oct 17, 2017, at 8:34 AM, Tom de Vries wrote:
OK, if full testing is ok?
I believe this was fully intentional and the presence/absence of
explicit dg-do run can then be used to decide if it should loop through
options or not.
I don't see an expl
Jakub Jelinek writes:
> 2017-10-18 Jakub Jelinek
>
> PR lto/82598
> * simple-object.c (handle_lto_debug_sections): Copy over also
> .note.GNU-stack section with unchanged name.
> * simple-object-elf.c (SHF_EXECINSTR): Define.
> (simple_object_elf_copy_lto_debug_se
Hi.
This fixes the test-case. Reason is that switch statement is not yet expanded
as decision tree,
which also contains a BB with count == 2000.
Ready for trunk?
Thanks,
Martin
>From 9845016dbcb4cd3160d49280c8d74b4851477496 Mon Sep 17 00:00:00 2001
From: marxin
Date: Wed, 18 Oct 2017 13:56:
> > According to Agner's tables, gathers range from 12 ops (vgatherdpd)
> > to 66 ops (vpgatherdd). I assume that CPU needs to do following:
> >
> > 1) transfer the offsets sse->ALU unit for address generation (3 cycles
> >each, 2 ops)
> > 2) do the address calcualtion (2 ops, probably 4 ops
> Hi.
>
> This fixes the test-case. Reason is that switch statement is not yet expanded
> as decision tree,
> which also contains a BB with count == 2000.
>
> Ready for trunk?
OK,
thanks
Honza
> Thanks,
> Martin
>
>
>
>
> >From 9845016dbcb4cd3160d49280c8d74b4851477496 Mon Sep 17 00:00:00 2
On Tue, Oct 17, 2017 at 6:05 PM, Richard Sandiford
wrote:
> Andrew MacLeod writes:
>> On 10/17/2017 08:18 AM, Richard Sandiford wrote:
>>> Aldy Hernandez writes:
Hi folks!
Calling print_hex() on a widest_int with the most significant bit turned
on can lead to a leading zero b
On 10/12/2017 10:48 AM, Jakub Jelinek wrote:
> On Thu, Oct 12, 2017 at 10:40:42AM +0200, Martin Liška wrote:
>> --- a/gcc/cp/constexpr.c
>> +++ b/gcc/cp/constexpr.c
>> @@ -1175,7 +1175,12 @@ cxx_eval_builtin_function_call (const constexpr_ctx
>> *ctx, tree t, tree fun,
>> {
>>new_call
Hello.
This is first patch that addresses test-suite fallout. All these tests fail in
runtime.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready to be installed?
Martin
>From f945460bccf6d54e790bf7c4cacac7cb5b915a28 Mon Sep 17 00:00:00 2001
From: marxin
Date: Tue
On Wed, Oct 18, 2017 at 02:46:23PM +0200, Martin Liška wrote:
> On 10/12/2017 10:48 AM, Jakub Jelinek wrote:
> > On Thu, Oct 12, 2017 at 10:40:42AM +0200, Martin Liška wrote:
> >> --- a/gcc/cp/constexpr.c
> >> +++ b/gcc/cp/constexpr.c
> >> @@ -1175,7 +1175,12 @@ cxx_eval_builtin_function_call (cons
On Wed, 18 Oct 2017, Jan Hubicka wrote:
> > > According to Agner's tables, gathers range from 12 ops (vgatherdpd)
> > > to 66 ops (vpgatherdd). I assume that CPU needs to do following:
> > >
> > > 1) transfer the offsets sse->ALU unit for address generation (3 cycles
> > >each, 2 ops)
> > >
On 10/18/2017 02:52 PM, Marek Polacek wrote:
> On Wed, Oct 18, 2017 at 02:46:23PM +0200, Martin Liška wrote:
>> On 10/12/2017 10:48 AM, Jakub Jelinek wrote:
>>> On Thu, Oct 12, 2017 at 10:40:42AM +0200, Martin Liška wrote:
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -1175,7
On 10/18/17 13:30, Segher Boessenkool wrote:
> On Wed, Oct 18, 2017 at 11:10:48AM +, Bernd Edlinger wrote:
>> A memory clobber would also make rtx_moveable_p return false,
>> thru the following case:
>>
>> case MEM:
>>if (type == OP_IN && MEM_READONLY_P (x))
>> return rtx_
And using range-info to constain parameters.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2017-10-18 Richard Biener
* graphite-isl-ast-to-gimple.c
(translate_isl_ast_to_gimple::set_rename): Simplify.
(translate_isl_ast_to_gimple::set_rename_
On Wed, Oct 18, 2017 at 06:30:23AM -0500, Segher Boessenkool wrote:
> On Wed, Oct 18, 2017 at 11:10:48AM +, Bernd Edlinger wrote:
> > A memory clobber would also make rtx_moveable_p return false,
> > thru the following case:
> >
> > case MEM:
> > if (type == OP_IN && MEM_READONLY_P (
On 10/18/17 15:46, Segher Boessenkool wrote:
> On Wed, Oct 18, 2017 at 06:30:23AM -0500, Segher Boessenkool wrote:
>> On Wed, Oct 18, 2017 at 11:10:48AM +, Bernd Edlinger wrote:
>>> A memory clobber would also make rtx_moveable_p return false,
>>> thru the following case:
>>>
>>> case MEM:
On Mon, Oct 16, 2017 at 08:56:05PM -0600, Martin Sebor wrote:
> On 10/16/2017 06:37 AM, Sam van Kampen via gcc-patches wrote:
> > ..I just realised that the clang flag is -Wbitfield-enum-conversion, not
> > -Wenum-bitfield-conversion. Please apply the patch below instead, which
> > has replaced the
> Hmm. It makes tracking DIE builds difficult now that not all allocations go
> through new_die anymore.
I wouldn't have created such a precedent though, IOW there is nothing new.
> Can you instead split out a new_die_raw
> function with just the allocation and the die_tag initialization? Or ma
On Mon, Oct 16, 2017 at 11:31:10PM +, Joseph Myers wrote:
> On Mon, 16 Oct 2017, Sam van Kampen via gcc-patches wrote:
>
> > +Wbitfield-enum-conversion
> > +C++ Var(warn_bitfield_enum_conversion) Init(1) Warning
> > +Warn about struct bit-fields being too small to hold enumerated types.
>
> A
> I'd think so. LANG_TYPE is treated specially in several
> places and Ada debug types are pretty sensitive so this would
> require caution but I don't see/know-of obvious reasons why this
> couldn't be done.
LANG_TYPE is only used in Ada to trigger the specific treatment in
gen_type_die_with_usa
> Are we in agreement that I should revert the patch?
I think that you can leave it for now in order to have some feedback (see for
example PR rtl-optimization/82597) but ideally it should be rewritten so as to
reuse the existing infrastructure of the pass.
--
Eric Botcazou
On Wed, Oct 18, 2017 at 01:50:31PM +, Bernd Edlinger wrote:
> Yes, the volatile is still necessary.
Certainly. And to work around the bug, it should work to mention some
hard register as asm input. Ideally something that is live anyway;
perhaps the stack pointer :-) Like so:
__asm volati
The following limits ISL operations done during optimized AST generation
as the PR shows it can take quite a bit of time.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2017-10-18 Richard Biener
PR tree-optimization/82591
* graphite.c (graphite_transf
Parallel builds of libstdc++ on APFS filesystem (with 1 ns granularity) on
macOS 10.13 often fail (failure rate for “make -j2” to “make -j8” is about 60%
from my own builds and results reported by others):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
This is reproducible with several versi
> > Those instructions seems similarly expensive in Intel implementation.
> > http://users.atw.hu/instlatx64/GenuineIntel0050654_SkylakeXeon9_InstLatX64.txt
> > lists latencies ranging from 18 to 32 cycles.
> >
> > Of course it may also be the case that the utility is measuring gathers
> > incorr
Hi,
On Wed, 18 Oct 2017, Segher Boessenkool wrote:
> Certainly. And to work around the bug, it should work to mention some
> hard register as asm input. Ideally something that is live anyway;
> perhaps the stack pointer :-) Like so:
>
> __asm volatile ("mrs %0,PRIMASK" : "=r" (status) :: "s
Fair enough, I didn't know whether to change the way it currently was
triggered. Do you think it should fall under -Wextra (I don't think it
falls under -Wall, since it isn't "easy to avoid or modify to prevent
the warning" because it may be valid and wanted behavior), or should it
be enabled by n
On Wed, Oct 18, 2017 at 05:17:19PM +0200, Michael Matz wrote:
> On Wed, 18 Oct 2017, Segher Boessenkool wrote:
>
> > Certainly. And to work around the bug, it should work to mention some
> > hard register as asm input. Ideally something that is live anyway;
> > perhaps the stack pointer :-) Lik
On 10/9/2017 12:20 PM, Mukesh Kapoor wrote:
Hi,
This patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82307.
For an unscoped enum with a fixed underlying type, the function
type_promotes_to() does not always return the same type as the
underlying type. The fix is to use the underlying
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82556
The patch was bootstrapped and tested on x86-64.
Committed to trunk as rev. 253862.
Committed to gcc-7-branch as rev. 253863.
Index: ChangeLog
===
--
Hello,
Test case "guality.exp=nrv-1.c" fails on aarch64. Optimizations reorder
the instructions and cause the value of a variable to be checked before
its first assignment. The following patch is moving the
break point to the end of the function. Therefore, it ensures that the
break point is r
It looks like the generic debug() function for wide_int's is missing.
Instead, we have a wi->dump() method. I have implemented debug() for
generic wide_int and for widest_int, which should cover the common
cases. Anything else, can continue using the ->dump() method
templated methods.
Also, do w
Hello Sergey,
On 06 Oct 14:20, Shalnov, Sergey wrote:
> Jakub,
> I completely agree with you. I fixed the patch.
> Currently, TARGET_PREFER256 will work on architectures with 512VL. It will
> not work otherwise.
>
> I will try to find better solution for this. I think I need to look into
> regis
On Wed, 18 Oct 2017, Richard Biener wrote:
> When overflow/underflow can be disregarded is there any reason remaining to
> make this guarded by flag_unsafe_math_optimizations? Are there any cases
> where rounding issues can flip the comparison result?
Yes. E.g. (in round-to-nearest) 3.0f * 0xff
On Wed, Oct 18, 2017 at 09:46:08AM -0600, Martin Sebor wrote:
> > Fair enough, I didn't know whether to change the way it currently was
> > triggered. Do you think it should fall under -Wextra (I don't think it
> > falls under -Wall, since it isn't "easy to avoid or modify to prevent
> > the warnin
On Oct 18, 2017, at 10:08 AM, Aldy Hernandez wrote:
>
> It looks like the generic debug() function for wide_int's is missing.
> OK for trunk?
Ok.
On 10/18/2017 06:48 AM, Segher Boessenkool wrote:
A volatile asm statement can not be moved (relative to other volatile
asm, etc.), but IRA could do it nevertheless. This patch fixes it.
Testing on powerpc64-linux {-m32,-m64}; okay if it succeeds? Also
for backports?
Although I am not an au
On 10/18/2017 12:17 PM, Mukesh Kapoor wrote:
On 10/9/2017 12:20 PM, Mukesh Kapoor wrote:
Hi,
This patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82307.
For an unscoped enum with a fixed underlying type, the function
type_promotes_to() does not always return the same type as the
unde
Hello!
Attached patch emulates double-word comparisons with a double-word
subtraction. Note that only comparisons that test Carry, Sign and
Overflow flags are valid, so we have to avoid comparisons that test
Zero flag.
2017-10-18 Uros Bizjak
PR target/82580
* config/i386/i386-modes.de
On Tue, 2017-10-17 at 20:05 +, Joseph Myers wrote:
> On Tue, 17 Oct 2017, David Malcolm wrote:
>
> > It also adds generalizes some of the code for this (and for the
> > "std::"
> > namespace hints in the C++ frontend), moving it to a new
> > c-family/known-headers.cc and .h, and introducing a
The bug happens only for enum types with a fixed underlying type. The
existing code tries to create another type based on it's precision by
calling c_common_type_for_size(). For the precision value of an unsigned
long long type, the call to c_common_type_for_size() returns an unsigned
long type
On Wed, 18 Oct 2017, David Malcolm wrote:
> +{"WINT_MAX", {"", NULL} },
> +{"WINT_MIN", {"", NULL} }
These are in / , not .
--
Joseph S. Myers
jos...@codesourcery.com
On Wed, 18 Oct 2017 16:51:37 +0200
FX wrote:
> Parallel builds of libstdc++ on APFS filesystem (with 1 ns granularity) on
> macOS 10.13 often fail
> (failure rate for “make -j2” to “make -j8” is about 60% from my own builds
> and results reported
> by others): https://gcc.gnu.org/bugzilla/show_
> From supplied info not follow that problem is on gcc build side.
> I can suspect that APFS has problem with direntry intensive
> modification, for example.
As part of Homebrew, we have built 4000+ open source codes on this new
filesystem, with parallel compilation. Some of them pretty intensive
On 18/10/17 16:51 +0200, FX wrote:
Parallel builds of libstdc++ on APFS filesystem (with 1 ns granularity) on
macOS 10.13 often fail (failure rate for “make -j2” to “make -j8” is about 60%
from my own builds and results reported by others):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
Th
From: Vladimir Mezentsev
FMA (floating-point multiply-add) instructions are supported on aarch64.
These instructions can produce different result if two operations executed
separately.
-ffp-contract=off doesn't allow the FMA instructions.
Tested on two platforms:
aarch64-unknown-linux-gnu: No
Hi Jerry and Steve,
Well I know 42 is the answer to the ultimate question of the universe so this
must be OK. I just don't know what the question is.
OK and thanks,
Jerry
+#define CONSTR_LEN_MAX 42
Actually, I was wondering about the choice myself. With
most common hardware having fairly r
> Could you test using .PHONY: install-headers instead?
> That target *is* phony, so telling make that seems sensible.
I’ve tried adding it to the existing .PHONY list:
Index: libstdc++-v3/include/Makefile.in
===
--- libstdc++-v3/inc
On 10/18/2017 06:08 PM, Aldy Hernandez wrote:
> Also, do we have a blessed way of specifying overloaded functions in
> ChangeLog's? I couldn't find anything in our GCC coding guidelines or
> in the GNU coding guidelines. For lack of direction, I'm doing the
> following:
>
> * wide-int.cc (debug
Richard Biener writes:
> On Fri, Oct 13, 2017 at 4:10 PM, Richard Sandiford
> wrote:
>> Normally we adjust the vector loop so that it iterates:
>>
>>(original number of scalar iterations - number of peels) / VF
>>
>> times, enforcing this using an IV that starts at zero and increments
>> by o
On Wed, 2017-10-18 at 20:40 +, Joseph Myers wrote:
> On Wed, 18 Oct 2017, David Malcolm wrote:
>
> > +{"WINT_MAX", {"", NULL} },
> > +{"WINT_MIN", {"", NULL} }
>
> These are in / , not .
Thanks; here's an updated version of the patch which fixes that.
OK for trunk once the prereqs
Aldy Hernandez writes:
> On Tue, Oct 17, 2017 at 6:05 PM, Richard Sandiford
> wrote:
>> Andrew MacLeod writes:
>>> On 10/17/2017 08:18 AM, Richard Sandiford wrote:
Aldy Hernandez writes:
> Hi folks!
>
> Calling print_hex() on a widest_int with the most significant bit turned
>>
On Wed, 18 Oct 2017, FX wrote:
> Parallel builds of libstdc++ on APFS filesystem (with 1 ns granularity) on
> macOS 10.13 often fail (failure rate for ?make -j2? to ?make -j8? is about
> 60% from my own builds and results reported by others):
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
On 10/18/2017 04:48 AM, Richard Biener wrote:
On Wed, Oct 18, 2017 at 5:34 AM, Martin Sebor wrote:
While testing my latest -Wrestrict changes I noticed a number of
opportunities to improve the -Warray-bounds warning. Attached
is a patch that implements a solution for the following subset
of th
config/plugins.m4 has
if test "$plugins" = "yes"; then
AC_SEARCH_LIBS([dlopen], [dl])
fi
Plugin uses dlsym, but libasan.so only intercepts dlopen, not dlsym:
[hjl@gnu-tools-1 binutils-text]$ nm -D /lib64/libasan.so.4| grep " dl"
00038580 W dlclose
U dl_iterate_phd
On 18/10/17 22:05 +0100, Jonathan Wakely wrote:
On 18/10/17 16:51 +0200, FX wrote:
Parallel builds of libstdc++ on APFS filesystem (with 1 ns granularity) on
macOS 10.13 often fail (failure rate for “make -j2” to “make -j8” is about 60%
from my own builds and results reported by others):
http
On 18/10/17 18:40 -0400, Hans-Peter Nilsson wrote:
On Wed, 18 Oct 2017, FX wrote:
Parallel builds of libstdc++ on APFS filesystem (with 1 ns granularity) on
macOS 10.13 often fail (failure rate for ?make -j2? to ?make -j8? is about 60%
from my own builds and results reported by others):
http
On 10/18/2017 01:15 PM, Sam van Kampen wrote:
On Wed, Oct 18, 2017 at 09:46:08AM -0600, Martin Sebor wrote:
Fair enough, I didn't know whether to change the way it currently was
triggered. Do you think it should fall under -Wextra (I don't think it
falls under -Wall, since it isn't "easy to avoi
On 10/18/2017 11:08 AM, Aldy Hernandez wrote:
It looks like the generic debug() function for wide_int's is missing.
Instead, we have a wi->dump() method. I have implemented debug() for
generic wide_int and for widest_int, which should cover the common
cases. Anything else, can continue using th
Hi
Any feedback regarding this patch ?
Thanks,
François
On 14/09/2017 22:04, François Dumont wrote:
I realized there was no test on the noexcept qualification of the move
constructor with allocator.
I added some and found out that patch was missing a noexcept
qualification at _Rb_tree l
> On 18 Oct 2017, at 15:59, Eric Botcazou wrote:
>
>> I'd think so. LANG_TYPE is treated specially in several
>> places and Ada debug types are pretty sensitive so this would
>> require caution but I don't see/know-of obvious reasons why this
>> couldn't be done.
>
> LANG_TYPE is only used in A
92 matches
Mail list logo
