The following fixes an ommision in find_constructor_constant_at_offset
to handle RANGE_EXPR in array constructor indices. The handling is
conservative in that it only handles the first index in the range.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk
sofar.
Richard.
201
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2017-06-19 Richard Biener
* tree-ssa-loop-niter.h (estimate_numbers_of_iterations): Take
struct function as arg.
(estimate_numbers_of_iterations): Export overload with loop arg.
(free_numbe
Hi Thomas,
On 15 June 2017 at 18:18, Thomas Preudhomme
wrote:
> 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 c
Hello Matthias,
thanks for review.
As far as I understood that build-id should look like this:
https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html
"For the “build ID” method, GDB looks in the .build-id subdirectory of
each one of the global debug directories for a file named
n
On Sat, Jun 17, 2017 at 9:35 AM, Marc Glisse wrote:
> Hello,
>
> see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80887#c10 for the context.
> FRE can go into an infinite recursion with some match.pd simplifications
> (that have been temporarily reverted).
>
> Limiting the depth of recursive calls
On 19/06/17 08:41, Christophe Lyon wrote:
Hi Thomas,
On 15 June 2017 at 18:18, Thomas Preudhomme
wrote:
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 some
Hi Jonathan,
> On 14/06/17 19:13 +0100, Jonathan Wakely wrote:
>>There are two symbols defined in GCC 7.1's libstdc++.6.0.23 library
>>which are not exported on all targets (because I wrote "m" in the
>>linker script instead of "[jmy]").
>>
>>This patch bumps the library version on gcc-7-branch to
On 12 June 2017 at 16:28, Tom de Vries wrote:
> On 06/12/2017 02:28 PM, Christophe Lyon wrote:
>>
>> Hi Tom,
>>
>> On 9 June 2017 at 17:25, Mike Stump wrote:
>>>
>>> On Jun 9, 2017, at 7:24 AM, Tom de Vries wrote:
this patch adds effective target stack_size.
>>>
>>>
OK for trunk i
On 19 June 2017 at 11:16, Thomas Preudhomme
wrote:
>
>
> On 19/06/17 08:41, Christophe Lyon wrote:
>>
>> Hi Thomas,
>>
>>
>> On 15 June 2017 at 18:18, Thomas Preudhomme
>> wrote:
>>>
>>> Hi,
>>>
>>> Conditions checked for ARM targets in vector-related effective targets
>>> are inconsistent:
>>>
>
I happened to notice that we have one last reference to long obsolete
Solaris versions in the testsuite. Fixed like this, tested with the
appropriate runtest invocation on i386-pc-solaris2.12, installed on
mainline.
Rainer
--
-
On 16/06/17 15:56, Prakhar Bahuguna wrote:
> On 16/06/2017 15:37:18, Richard Earnshaw (lists) wrote:
>> On 16/06/17 08:48, Prakhar Bahuguna wrote:
>>> On 15/06/2017 17:23:43, Richard Earnshaw (lists) wrote:
On 14/06/17 10:35, Prakhar Bahuguna wrote:
> The ARM ACLE defines the __ARM_FEATURE
Hi,
this patch makes us to track quality of the profile. This is useful
to disable some agressive optimizations when counts are known to be
unreliable.
Bootstrapped/regtested x86_64-linux,
Honza
* profile-count.c (profile_count::dump): Dump quality.
(profile_count::differs_from_p)
From: claziss
Hi Andrew,
Apologizes for the disconfort, please find the patch that works on the head.
Thanks,
Claudiu
gcc/
2016-12-13 Claudiu Zissulescu
Andrew Burgess
* config/arc/arc-protos.h (arc_compute_function_type): Change prototype.
(arc_return_address
On 19/06/17 11:18 +0200, Rainer Orth wrote:
Hi Jonathan,
On 14/06/17 19:13 +0100, Jonathan Wakely wrote:
There are two symbols defined in GCC 7.1's libstdc++.6.0.23 library
which are not exported on all targets (because I wrote "m" in the
linker script instead of "[jmy]").
This patch bumps th
On Tue, Jun 13, 2017 at 03:29:32PM +, Joseph Myers wrote:
> On Tue, 13 Jun 2017, Marek Polacek wrote:
>
> > * c-parser.c (c_parser_if_body): Set the location of the
> > body of the conditional after parsing all the labels. Call
> > warn_for_multistatement_macros.
> > (c_parser
On Mon, 19 Jun 2017, Richard Biener wrote:
On Sat, Jun 17, 2017 at 9:35 AM, Marc Glisse wrote:
Hello,
see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80887#c10 for the context.
FRE can go into an infinite recursion with some match.pd simplifications
(that have been temporarily reverted).
Li
PING^2
On 06/06/2017 08:59 AM, Martin Liška wrote:
> PING^1
>
> On 05/25/2017 12:05 PM, Martin Liška wrote:
>> Hello.
>>
>> Following patch tries to resolve following 2 issues:
>>
>> a) When one takes address of a function that uses target_clones attribute,
>> default implementation is always
PING^2
On 06/06/2017 08:58 AM, Martin Liška wrote:
> PING^1
>
> On 05/26/2017 01:05 PM, Martin Liška wrote:
>> Hello.
>>
>> Unfortunately I guarded use-after-scope to track live switch variables just
>> to BIND_EXPR. However the bind expression can be included in a
>> STATEMENT_LIST.
>> That ena
> Hello.
>
> Following patch tries to resolve following 2 issues:
>
> a) When one takes address of a function that uses target_clones attribute,
>default implementation is always returned.
>
> b) Using dlsym("foo") should work and thus the resolver function should
>use the default name.
> On 05/29/2017 07:04 AM, Markus Trippelsdorf wrote:
> > On 2017.05.25 at 11:55 +0200, Martin Liška wrote:
> >> Hi.
> >>
> >> As I spoke about the PGO with Honza and Richi, current 3-stage is not
> >> ideal for following
> >> 2 reasons:
> >>
> >> 1) stageprofile compiler is train just on libraries
Wrong copy paste between the patch I tested and the patch I sent. The first and
second command of the sed should be replaced, not the second and third as in the
patch I sent. For more safety I'll rerun the tests.
Best regards,
Thomas
On 15/06/17 17:15, Thomas Preudhomme wrote:
Forgetting the
PING^1
Richi are you fine with the suggested change? I basically followed your advises
:)
Martin
On 05/26/2017 03:00 PM, Martin Liška wrote:
> On 05/26/2017 01:55 PM, Richard Biener wrote:
>> On Fri, May 26, 2017 at 1:51 PM, Jakub Jelinek wrote:
>>> On Fri, May 26, 2017 at 01:46:47PM +0200, Ri
> Ok, you're right that we can preserve the predictor. However, let's consider
> following test-case:
>
> static
> int baz(int a)
> {
> if (a == 1)
> return 1;
>
> return 0;
> }
>
>
> static
> int bar(int a)
> {
> if (a == 1)
> return baz(a);
>
> return 0;
> }
>
> static
On Mon, Jun 19, 2017 at 12:09 PM, Marc Glisse wrote:
> On Mon, 19 Jun 2017, Richard Biener wrote:
>
>> On Sat, Jun 17, 2017 at 9:35 AM, Marc Glisse wrote:
>>>
>>> Hello,
>>>
>>> see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80887#c10 for the
>>> context.
>>> FRE can go into an infinite recursi
The following limits the number of mprts_hook invocations from a single
simplification in SCCVN to avoid endless recursion.
I thought a GIMPLE testcase is in order here and thus extended
parsing to handle a_10 + -1 aka a_10 + _Literal (int) -1. I did
so in a straight-forward way rather than simp
On 19 June 2017 at 12:44, Thomas Preudhomme
wrote:
> Wrong copy paste between the patch I tested and the patch I sent. The first
> and second command of the sed should be replaced, not the second and third
> as in the patch I sent. For more safety I'll rerun the tests.
>
OK great. If you send an
On Mon, Jun 19, 2017 at 12:51 PM, Martin Liška wrote:
> PING^1
>
> Richi are you fine with the suggested change? I basically followed your
> advises :)
Well, I am but as Eric disagrees I think we need input from other
people on this.
I'm comfortably setting STAGE1_CFLAGS here.
Richard.
> Marti
Hi Richard,
On 16 June 2017 at 14:18, Richard Biener wrote:
> On Wed, 14 Jun 2017, Richard Biener wrote:
>
>>
>> niter estimates are not kept up-to-date (they reference gimple stmts
>> and trees) in the keep-loop-stuff infrastructure so similar to the
>> SCEV cache we rely on people freeing it af
On Mon, 19 Jun 2017, Christophe Lyon wrote:
> Hi Richard,
>
> On 16 June 2017 at 14:18, Richard Biener wrote:
> > On Wed, 14 Jun 2017, Richard Biener wrote:
> >
> >>
> >> niter estimates are not kept up-to-date (they reference gimple stmts
> >> and trees) in the keep-loop-stuff infrastructure so
On 2017-06-12 09:26 +0800, Xi Ruoyao wrote:
> Hi,
>
> I've implemented -Wstring-plus-int and -Wstring-plus-char (like their
> counterpart in Clang) for GCC.
>
> This series of patch has been bootstrapped and regtested. OK for trunk?
>
> Currently these options are not enabled by default like Cl
On 06/19/2017 12:35 PM, Jan Hubicka wrote:
>> Hello.
>>
>> Following patch tries to resolve following 2 issues:
>>
>> a) When one takes address of a function that uses target_clones attribute,
>>default implementation is always returned.
>>
>> b) Using dlsym("foo") should work and thus the reso
On Fri, May 26, 2017 at 01:05:28PM +0200, Martin Liška wrote:
> Hello.
>
> Unfortunately I guarded use-after-scope to track live switch variables just
> to BIND_EXPR. However the bind expression can be included in a STATEMENT_LIST.
> That enables proper tracking and fixes the test added.
>
> Patc
On Tue, Jun 13, 2017 at 12:08 PM, Richard Biener
wrote:
> On Tue, Jun 13, 2017 at 1:06 PM, Richard Biener
> wrote:
>> On Mon, Jun 12, 2017 at 7:02 PM, Bin Cheng wrote:
>>> Hi,
>>> This simple patch computes and preserves loop nest vector for whole
>>> distribution
>>> life time. The loop nest
On Tue, Jun 13, 2017 at 12:14 PM, Richard Biener
wrote:
> On Mon, Jun 12, 2017 at 7:02 PM, Bin Cheng wrote:
>> Hi,
>> This patch collects and preserves all data references in loop for whole
>> distribution life time. It will be used afterwards.
>>
>> Bootstrap and test on x86_64 and AArch64. Is
On 16/06/17 22:08, Michael Collison wrote:
> This patch improves code generation for literal vector construction by
> expanding and exposing the pattern to rtl optimization earlier. The current
> implementation delays splitting the pattern until after reload which results
> in poor code generati
On Wed, Jun 14, 2017 at 2:47 PM, Richard Biener
wrote:
> On Mon, Jun 12, 2017 at 7:03 PM, Bin Cheng wrote:
>> Hi,
>> This patch refactors struct partition for later distribution. It records
>> bitmap of data references in struct partition rather than vertices' data in
>> partition dependence gra
On Wed, Jun 14, 2017 at 2:54 PM, Richard Biener
wrote:
> On Mon, Jun 12, 2017 at 7:03 PM, Bin Cheng wrote:
>> Hi,
>> Current primitive cost model merges partitions with data references sharing
>> the same
>> base address. I believe it's designed to maximize data reuse in
>> distribution, but
>
Many parallel set insns are of the form of a single set that also sets
the condition code flags. In this case the cost of such an insn is
normally the cost of the part that doesn't set the flags, since updating
the condition flags is simply a side effect.
At present all such insns are treated as
Hi.
Following patch addresses issue where we have a function argument which address
is taken and -fsanitize=address does not wrap up the argument with red zone.
It's done in sanopt pass, where I create a new automatic variable which is used
in the function instead of the original argument.
Patch
Hi!
On Mon, Jun 19, 2017 at 02:46:59PM +0100, Richard Earnshaw (lists) wrote:
> Many parallel set insns are of the form of a single set that also sets
> the condition code flags. In this case the cost of such an insn is
> normally the cost of the part that doesn't set the flags, since updating
>
On 19/06/17 10:16, Thomas Preudhomme wrote:
On 19/06/17 08:41, Christophe Lyon wrote:
Hi Thomas,
On 15 June 2017 at 18:18, Thomas Preudhomme
wrote:
Hi,
Conditions checked for ARM targets in vector-related effective targets
are inconsistent:
* sometimes arm*-*-* is checked
* sometimes N
On Mon, Jun 19, 2017 at 03:50:42PM +0200, Martin Liška wrote:
> @@ -858,6 +862,117 @@ sanitize_asan_mark_poison (void)
> }
> }
>
Missing function comment.
> +static tree
> +rewrite_usage_of_param (tree *op, int *walk_subtrees, void *data)
> +{
> + struct walk_stmt_info *wi = (struct walk
This fixes pr 81119. My rewriting of name lookup was a little too eager
to warn about constructor hiding. This restores the earlier behaviour
of only warning when hiding via a function.
nathan
--
Nathan Sidwell
2017-06-19 Nathan Sidwell
PR c++/81119
* name-lookup.c (update_binding): Onl
I discovered a cleanup I'd forgotten about. The only unobvious thing
about this patch is that just before the second hunk we've already set
DECL_RTL to NULL. No need to do it twice.
nathan
--
Nathan Sidwell
2017-06-19 Nathan Sidwell
* pt.c (coerce_template_parms): Fix indentation.
(tsu
On 19/06/17 15:08, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jun 19, 2017 at 02:46:59PM +0100, Richard Earnshaw (lists) wrote:
>> Many parallel set insns are of the form of a single set that also sets
>> the condition code flags. In this case the cost of such an insn is
>> normally the cost of
On 19 June 2017 at 16:11, Thomas Preudhomme
wrote:
>
>
> On 19/06/17 10:16, Thomas Preudhomme wrote:
>>
>>
>>
>> On 19/06/17 08:41, Christophe Lyon wrote:
>>>
>>> Hi Thomas,
>>>
>>>
>>> On 15 June 2017 at 18:18, Thomas Preudhomme
>>> wrote:
Hi,
Conditions checked for ARM targe
On Mon, Jun 19, 2017 at 09:16:58AM +0200, Richard Biener wrote:
>
> The following fixes an ommision in find_constructor_constant_at_offset
> to handle RANGE_EXPR in array constructor indices. The handling is
> conservative in that it only handles the first index in the range.
>
> Bootstrapped an
Hi!
Martin's recent patch that introduced sanitize_flags_p causes us to
instrument operations even when current_function_decl is NULL. If it
is valid constant expression it will be folded away soon, otherwise
usually we emit a runtime initializer in the static ctors function for
it. In any case,
On Mon, 19 Jun 2017, Jakub Jelinek wrote:
> Hi!
>
> Martin's recent patch that introduced sanitize_flags_p causes us to
> instrument operations even when current_function_decl is NULL. If it
> is valid constant expression it will be folded away soon, otherwise
> usually we emit a runtime initial
On 19/06/17 15:08, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jun 19, 2017 at 02:46:59PM +0100, Richard Earnshaw (lists) wrote:
>> Many parallel set insns are of the form of a single set that also sets
>> the condition code flags. In this case the cost of such an insn is
>> normally the cost of
Hi!
And here is another ICE. While we have a current_function_decl
in this case, still create_tmp_var's called gimple_add_tmp_var
and mark_addressable don't work too well when the current function
is a C++ ctor or dtor that the FE then duplicates.
Fixed by telling ubsan_encode_value whether it i
On 19/06/17 15:31, Christophe Lyon wrote:
On 19 June 2017 at 16:11, Thomas Preudhomme
wrote:
On 19/06/17 10:16, Thomas Preudhomme wrote:
On 19/06/17 08:41, Christophe Lyon wrote:
Hi Thomas,
On 15 June 2017 at 18:18, Thomas Preudhomme
wrote:
Hi,
Conditions checked for ARM targets
On Mon, 19 Jun 2017, Jakub Jelinek wrote:
> Hi!
>
> And here is another ICE. While we have a current_function_decl
> in this case, still create_tmp_var's called gimple_add_tmp_var
> and mark_addressable don't work too well when the current function
> is a C++ ctor or dtor that the FE then duplic
On Mon, Jun 19, 2017 at 03:28:20PM +0100, Richard Earnshaw (lists) wrote:
> > That's not what combine does: it optimistically assumes any combination
> > with unknown costs is an improvement.
>
> So try this testcase on ARM.
>
> unsigned long x, y, z;
> int b;
> void test()
> {
>b = __builtin
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2017-06-19 Richard Biener
PR middle-end/81118
* tree-cfgcleanup.c (cleanup_tree_cfg_noloop): Clear niter
estimates if we changed anything.
* gcc.dg/torture/pr81118.c: New testcase.
Index:
On Nov 19 2016, Jeff Law wrote:
> diff --git a/gcc/config/m68k/m68k.md b/gcc/config/m68k/m68k.md
> index 7b7f373..2085619 100644
> --- a/gcc/config/m68k/m68k.md
> +++ b/gcc/config/m68k/m68k.md
> @@ -5336,6 +5336,45 @@
> }
>[(set_attr "type" "bitrw")])
>
> +(define_insn "*bsetdreg"
> + [(s
On Mon, Jun 19, 2017 at 03:45:23PM +0100, Richard Earnshaw (lists) wrote:
> >> At present all such insns are treated as having unknown cost (ie 0) and
> >> combine assumes that such insns are infinitely more expensive than any
> >> other insn sequence with a non-zero cost.
> >
> > That's not what
On Mon, Jun 19, 2017 at 3:32 PM, Bin.Cheng wrote:
> On Tue, Jun 13, 2017 at 12:08 PM, Richard Biener
> wrote:
>> On Tue, Jun 13, 2017 at 1:06 PM, Richard Biener
>> wrote:
>>> On Mon, Jun 12, 2017 at 7:02 PM, Bin Cheng wrote:
Hi,
This simple patch computes and preserves loop nest vecto
On Mon, Jun 19, 2017 at 3:34 PM, Bin.Cheng wrote:
> On Tue, Jun 13, 2017 at 12:14 PM, Richard Biener
> wrote:
>> On Mon, Jun 12, 2017 at 7:02 PM, Bin Cheng wrote:
>>> Hi,
>>> This patch collects and preserves all data references in loop for whole
>>> distribution life time. It will be used afte
On Mon, Jun 19, 2017 at 3:37 PM, Bin.Cheng wrote:
> On Wed, Jun 14, 2017 at 2:47 PM, Richard Biener
> wrote:
>> On Mon, Jun 12, 2017 at 7:03 PM, Bin Cheng wrote:
>>> Hi,
>>> This patch refactors struct partition for later distribution. It records
>>> bitmap of data references in struct partitio
On Mon, Jun 19, 2017 at 3:40 PM, Bin.Cheng wrote:
> On Wed, Jun 14, 2017 at 2:54 PM, Richard Biener
> wrote:
>> On Mon, Jun 12, 2017 at 7:03 PM, Bin Cheng wrote:
>>> Hi,
>>> Current primitive cost model merges partitions with data references sharing
>>> the same
>>> base address. I believe it'
Hi!
This testcase started to ICE when PR70873 fix changed the splitter:
@@ -5153,11 +5147,11 @@
;; slots when !TARGET_INTER_UNIT_MOVES_TO_VEC disables the general_regs
;; alternative in sse2_loadld.
(define_split
- [(set (match_operand:MODEF 0 "register_operand")
+ [(set (match_operand:MODEF
On Jun 19, 2017, at 2:21 AM, Christophe Lyon wrote:
>
> The attached patch removes the support for STACK_SIZE in the testcase
> as you suggested, and it works fine (cross-tested on aarch64/arm targets)
>
> OK for trunk?
Ok.
On Jun 14, 2017, at 5:30 AM, Thomas Preudhomme
wrote:
>
> 2017-06-14 Thomas Preud'homme
>
> * dg-cmp-results.sh: Keep test result lines rather than throwing
> header and summary to support sum files with multiple tools.
>
> Tested successfully on sum file with single tool with s
On Mon, Jun 19, 2017 at 4:16 PM, Richard Biener
wrote:
> On Mon, Jun 19, 2017 at 3:34 PM, Bin.Cheng wrote:
>> On Tue, Jun 13, 2017 at 12:14 PM, Richard Biener
>> wrote:
>>> On Mon, Jun 12, 2017 at 7:02 PM, Bin Cheng wrote:
Hi,
This patch collects and preserves all data references in l
On 19/06/17 16:09, Segher Boessenkool wrote:
> On Mon, Jun 19, 2017 at 03:45:23PM +0100, Richard Earnshaw (lists) wrote:
At present all such insns are treated as having unknown cost (ie 0) and
combine assumes that such insns are infinitely more expensive than any
other insn sequence
On Fri, Jun 16, 2017 at 11:07:41AM +0100, Kyrill Tkachov wrote:
>
> On 16/06/17 10:07, James Greenhalgh wrote:
> >On Wed, Jun 14, 2017 at 11:21:30AM +0100, Kyrill Tkachov wrote:
> >
> > <...>
> >
> >>That movv2di expander is the one in vec-common.md that ends up calling
> >>neon_make_constant. I
On 06/11/2017 07:26 PM, Xi Ruoyao wrote:
Hi,
I've implemented -Wstring-plus-int and -Wstring-plus-char (like their
counterpart in Clang) for GCC.
From the Clang patch(*) it only "warns when a character literal is
added (using '+') to a variable with type 'char *' (or any other
pointer to chara
This is a re-ping of:
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00021.html
It was pointed out to me that my original subject line [PATCH/AARCH64] might
be misleading since the patch is not to code in config/aarch64. It is to
ccmp.c which is in the shared gcc directory. That said, a
On 06/11/2017 07:34 PM, Xi Ruoyao wrote:
This patch adds warning option -Wstring-plus-char for C/C++.
+void
+warn_if_string_plus_char (location_t loc, tree ptrtype, tree inttype)
+{
+ if (POINTER_TYPE_P (ptrtype)
+ && type_main_variant_is_char (TREE_TYPE (ptrtype))
+ && type_main_va
On 19/06/17 17:16, James Greenhalgh wrote:
On Fri, Jun 16, 2017 at 11:07:41AM +0100, Kyrill Tkachov wrote:
On 16/06/17 10:07, James Greenhalgh wrote:
On Wed, Jun 14, 2017 at 11:21:30AM +0100, Kyrill Tkachov wrote:
<...>
That movv2di expander is the one in vec-common.md that ends up calli
On 06/11/2017 07:32 PM, Xi Ruoyao wrote:
This patch adds warning option -Wstring-plus-int for C/C++.
gcc/ChangeLog:
2017-06-12 Xi Ruoyao
* c-family/c.opt: New option -Wstring-plus-int.
* c-family/c-common.c (pointer_int_sum): Checking for
-Wstring-plus-int.
This is
On 06/11/2017 07:39 PM, Xi Ruoyao wrote:
This patch adds document of -Wstring-plus-int and -Wstring-plus-char.
+@item -Wstring-plus-char
+@opindex Wstring-plus-char
+@opindex Wno-string-plus-char
+Warn for adding a character to a string pointer, which seems like a failed
+attempt to append to t
As some of you are likely aware, Qualys has just published fairly
detailed information on using stack/heap clashes as an attack vector.
Eric B, Michael M -- sorry I couldn't say more when I contact you about
-fstack-check and some PPC specific stuff. This has been under embargo
for the last month.
[ was: Re: [PATCH, testsuite] Add effective target stack_size ]
On 06/09/2017 05:25 PM, Mike Stump wrote:
On Jun 9, 2017, at 7:24 AM, Tom de Vries wrote:
this patch adds effective target stack_size.
OK for trunk if x86_64 and nvptx testing succeeds?
Ok.
Hi,
I came across dg-add-options, an
On 2017-06-19 10:51 -0600, Martin Sebor wrote:
> On 06/11/2017 07:32 PM, Xi Ruoyao wrote:
> > This patch adds warning option -Wstring-plus-int for C/C++.
> >
> > gcc/ChangeLog:
> >
> > 2017-06-12 Xi Ruoyao
> >
> > * c-family/c.opt: New option -Wstring-plus-int.
> > * c-family/c-common
On Mon, Jun 19, 2017 at 11:07:06AM -0600, Jeff Law wrote:
> After much poking around I concluded that we really need to implement
> allocation and probing via a "moving sp" strategy. Probing into
> unallocated areas runs afoul of valgrind, so that's a non-starter.
>
> Allocating stack space, the
On 2017-06-19 10:30 -0600, Martin Sebor wrote:
> On 06/11/2017 07:34 PM, Xi Ruoyao wrote:
> > This patch adds warning option -Wstring-plus-char for C/C++.
> >
>
> +void
> +warn_if_string_plus_char (location_t loc, tree ptrtype, tree inttype)
> +{
> + if (POINTER_TYPE_P (ptrtype)
> + && type
On Jun 19, 2017, at 10:11 AM, Tom de Vries wrote:
>
> I came across dg-add-options, and wondered if adding a dg-add-options feature
> stack_size is a better way to make STACK_SIZE available.
I don't have a strong opinion here, but, it does look a tad simpler and nicer.
> OK if complete and tes
On Mon, Jun 19, 2017 at 05:01:10PM +0100, Richard Earnshaw (lists) wrote:
> Yeah, and I'm not suggesting we change the logic there (sorry if the
> description was misleading). Instead I'm proposing that we handle more
> cases for parallels to not return zero.
Right. My test run is half way throu
The testcase successfully compiles, but then fails to link because
we've optimized away the declaration of the variable. We catch this
in potential_constant_expression_1, but this path wasn't calling it.
Fixed on trunk by always calling that function, not just in templates.
With that change, I ne
Hi!
bootstrap-ubsan shows a couple of:
../../gcc/tree-chkp.c:694:37: runtime error: shift exponent 63 is too large for
32-bit type 'int'
errors.
1 << (TYPE_PRECISION (ptr_type_node) - 1)
should have been obviously
HOST_WIDE_INT_1U << (TYPE_PRECISION (ptr_type_node) - 1)
but even then, it is 1) u
On 06/19/2017 11:29 AM, Jakub Jelinek wrote:
>
> Also, on i?86 orq $0, (%rsp) or orl $0, (%esp) is used to probe stack,
> while it is shorter, is it actually faster or as slow as movq $0, (%rsp)
> or movl $0, (%esp) ?
Florian raised this privately to me as well. THere's a couple issues.
1. Is th
Hi!
Another easy to fix bug reported by bootstrap-ubsan.
We check that rhsunitoffset fits into shwi, but even if it does,
8x that might not, in which case we trigger UB.
Fixed by doing the multiplication in unsigned HWI type to make it well
defined.
Bootstrapped/regtested on x86_64-linux and i686
On Mon, 19 Jun 2017, Jeff Law wrote:
> A key point to remember is that you can never have an allocation
> (potentially using more than one allocation site) which is larger than a
> page without probing the page.
There's a platform ABI issue here. At least some kernel fixes for these
stack issue
On June 19, 2017 7:46:03 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>Another easy to fix bug reported by bootstrap-ubsan.
>We check that rhsunitoffset fits into shwi, but even if it does,
>8x that might not, in which case we trigger UB.
>Fixed by doing the multiplication in unsigned HWI type to mak
On Mon, Jun 19, 2017 at 11:45:13AM -0600, Jeff Law wrote:
> On 06/19/2017 11:29 AM, Jakub Jelinek wrote:
> >
> > Also, on i?86 orq $0, (%rsp) or orl $0, (%esp) is used to probe stack,
> > while it is shorter, is it actually faster or as slow as movq $0, (%rsp)
> > or movl $0, (%esp) ?
> Florian ra
On Mon, Jun 19, 2017 at 05:50:56PM +, Joseph Myers wrote:
> On Mon, 19 Jun 2017, Jeff Law wrote:
>
> > A key point to remember is that you can never have an allocation
> > (potentially using more than one allocation site) which is larger than a
> > page without probing the page.
>
> There's a
On June 19, 2017 7:29:32 PM GMT+02:00, Jakub Jelinek wrote:
>On Mon, Jun 19, 2017 at 11:07:06AM -0600, Jeff Law wrote:
>> After much poking around I concluded that we really need to implement
>> allocation and probing via a "moving sp" strategy. Probing into
>> unallocated areas runs afoul of va
Hi Dominique,
For the record, the following CSHIFT is still 4 times slower than the DO loop
I have looked into this a bit. The main reason is that, unlike cshift0
(without the array as shift) we do not generate individual functions to
call for the usual data types, we use memcpy with a size de
2017-06-19 20:43 GMT+03:00 Jakub Jelinek :
> Hi!
>
> bootstrap-ubsan shows a couple of:
> ../../gcc/tree-chkp.c:694:37: runtime error: shift exponent 63 is too large
> for 32-bit type 'int'
> errors.
>
> 1 << (TYPE_PRECISION (ptr_type_node) - 1)
> should have been obviously
> HOST_WIDE_INT_1U << (
On June 19, 2017 8:00:19 PM GMT+02:00, Richard Biener
wrote:
>On June 19, 2017 7:29:32 PM GMT+02:00, Jakub Jelinek
>wrote:
>>On Mon, Jun 19, 2017 at 11:07:06AM -0600, Jeff Law wrote:
>>> After much poking around I concluded that we really need to
>implement
>>> allocation and probing via a "movi
Out of curiousity, does the old Alpha/VMS stack-checking API meet the
requirements? From what I recall, I think it does.
On 06/19/2017 08:02 PM, Richard Biener wrote:
> Oh, and using push intelligently with first bumping to SP & 4096-1 + 4095
> would solve the signal atomicity as well. Might be larger and somewhat
> interfere with CPUs stack engine. Who knows...
On x86-64, PUSH REG is just a single byte, so for s
On 06/19/2017 07:50 PM, Joseph Myers wrote:
> There's a platform ABI issue here. At least some kernel fixes for these
> stack issues, as I understand it, increase the size of the stack guard to
> more than a single page. It would be possible to define the ABI to
> require such a larger guard f
Hi!
The following patch adds -fsanitize=pointer-overflow support,
which adds instrumentation (included in -fsanitize=undefined) that checks
that pointer arithmetics doesn't wrap. If the offset on ptr p+ off when
treating
it as signed value is non-negative, we check whether the result is bigger
(
On 06/19/2017 11:28 AM, Xi Ruoyao wrote:
On 2017-06-19 10:51 -0600, Martin Sebor wrote:
On 06/11/2017 07:32 PM, Xi Ruoyao wrote:
This patch adds warning option -Wstring-plus-int for C/C++.
gcc/ChangeLog:
2017-06-12 Xi Ruoyao
* c-family/c.opt: New option -Wstring-plus-int.
Aarch64_legitimate_constant_p currently returns false for symbols,
eventhough they are always valid constants. This means LOSYM isn't
CSEd correctly. If we return true CSE works better, resulting in
smaller/faster code (0.3% smaller code on SPEC2006).
int x0 = 1, x1 = 2, x2 = 3;
int
f (int x,
On 06/19/2017 11:50 AM, Joseph Myers wrote:
> On Mon, 19 Jun 2017, Jeff Law wrote:
>
>> A key point to remember is that you can never have an allocation
>> (potentially using more than one allocation site) which is larger than a
>> page without probing the page.
>
> There's a platform ABI issue h
This fixes 81124, where we used ovl_iterate to iterate over a lookup
result. We should always use lkp_iterate in those circumstances.
However, regular lookup is not what we want here. We don't want to
follow using directives -- just look in the local inline hierarchy.
Plus also ignore decls
1 - 100 of 123 matches
Mail list logo
