Re: [PATCH] add uClibc target hook (PR bootstrap/77819)

On 10/03/2016 12:02 AM, Martin Sebor wrote: I couldn't find a good uclibc-only file where to put the new definition of the hook so I conditionally added it to targethooks.c. diff --git a/gcc/targhooks.c b/gcc/targhooks.c index d75650f..77b4a18 100644 --- a/gcc/targhooks.c +++ b/gcc/targhooks.c

Re: [PATCH 2/2] Extend -falign-FOO=N to N[,M[,N2[,M2]]]

On 09/29/2016 07:32 PM, Denys Vlasenko wrote: On 09/29/2016 04:45 PM, Bernd Schmidt wrote: On 09/28/2016 02:57 PM, Denys Vlasenko wrote: - /* Comes from final.c -- no real reason to change it. */ -#define MAX_CODE_ALIGN 16 - case OPT_malign_loops_: warning_at (loc, 0, "-m

Re: [PATCH] Fix -Wimplicit-fallthrough -C, handle some more comment styles and comments in between FALLTHRU comment and label

On 09/30/2016 12:51 PM, Jakub Jelinek wrote: On Fri, Sep 30, 2016 at 12:42:20PM +0200, Bernd Schmidt wrote: On 09/30/2016 11:45 AM, Jakub Jelinek wrote: See Tom Tromey's explanation why accepting too much is bad (at least unless we want multiple levels). And I still don't buy it

Re: [PATCH] Fix -Wimplicit-fallthrough -C, handle some more comment styles and comments in between FALLTHRU comment and label

On 09/30/2016 11:45 AM, Jakub Jelinek wrote: See Tom Tromey's explanation why accepting too much is bad (at least unless we want multiple levels). And I still don't buy it. The case where someone writes "Don't fall through" is artificial to begin with, and also forgetting to put the break; t

Re: [PATCH] Machine-readable RTL dumps: print_rtx_function

On 09/29/2016 07:47 PM, David Malcolm wrote: This patch adds a new function, print_rtx_function, intended for use for generating function dumps suitable for parsing by the RTL frontend, but also intended to be human-readable, and human-authorable. (note 1 0 4 (nil) NOTE_INSN_DELETED)

Re: [PATCH 2/2] Extend -falign-FOO=N to N[,M[,N2[,M2]]]

On 09/28/2016 02:57 PM, Denys Vlasenko wrote: This change makes it possible to align functions to 64-byte boundaries *if* this does not introduce huge amount of padding. I'm still somewhat undecided, but it seems like a decent enough way to expose these possibilities to the user, so unless so

Re: Patch ping

On 09/28/2016 11:40 PM, Jakub Jelinek wrote: On Wed, Sep 28, 2016 at 11:17:55PM +0200, Bernd Schmidt wrote: On 09/28/2016 09:47 PM, Jakub Jelinek wrote: And here are the 0 < var to var > 0 changes. Thoughts on those? I kind of meant it the other way round, so yeah, please install.

Re: Patch ping

On 09/28/2016 09:47 PM, Jakub Jelinek wrote: And here are the 0 < var to var > 0 changes. Thoughts on those? I kind of meant it the other way round, so yeah, please install. Bernd

Re: Patch ping

On 09/28/2016 09:24 PM, Jakub Jelinek wrote: I'd like to ping the http://gcc.gnu.org/ml/gcc-patches/2016-09/msg01436.html patch, containing various fixes for gimple-ssa-sprintf.c. If the 0 < var to var > 0 changes are deemed too controversial, I can separate them from the other changes. I'd l

Re: Implement -Wimplicit-fallthrough (version 9)

On 09/28/2016 02:15 PM, Michael Matz wrote: P.S.: Initially I even wanted to argue that the mere existence of _any_ comment before a case label would disable the warning. I don't have the numbers but I bet even that version would have found the very same bugs that the picky version has. Sounds

Re: [PATCH] print-rtx.c: add 'h', v' and 'p' prefixes to regnos

On 09/28/2016 06:36 PM, Jeff Law wrote: A "p" prefix for pseudos might still be a good idea, but there's still the issue of a real "p0" register name causing confusion. So how do you think we should deal with distinguishing between the different registers that may appear in a dump file? I thin

Re: [PATCH] print-rtx.c: add 'h', v' and 'p' prefixes to regnos

On 09/28/2016 06:23 PM, Jeff Law wrote: (reg/i:SI h0 ax) (reg/i:SF h21 xmm0) (Replying to myself, in the hope of better demonstrating the idea) The following patch implements this idea for RTL dumps, so that all REGNO values in dumps get a one character prefix: 'h' for hard registers, 'v'

Re: Implement -Wimplicit-fallthrough (version 9)

On 09/27/2016 05:04 PM, Jakub Jelinek wrote: On Tue, Sep 27, 2016 at 9:56 AM, Michael Matz wrote: All those bugs would also have been found as well when it had simply accepted /fall.*thr/i anywhere in the preceding comment on one line. But all the recent spelling changes of comments to cater

Re: Implement -Wimplicit-fallthrough (version 9)

On 09/27/2016 03:49 PM, Jakub Jelinek wrote: On Tue, Sep 27, 2016 at 03:48:07PM +0200, Bernd Schmidt wrote: On 09/27/2016 02:01 PM, Marek Polacek wrote: On Tue, Sep 27, 2016 at 01:55:22PM +0200, Bernd Schmidt wrote: On 09/27/2016 01:51 PM, Marek Polacek wrote: But the C/C++ keywords are all

Re: Implement -Wimplicit-fallthrough (version 9)

On 09/27/2016 02:01 PM, Marek Polacek wrote: On Tue, Sep 27, 2016 at 01:55:22PM +0200, Bernd Schmidt wrote: On 09/27/2016 01:51 PM, Marek Polacek wrote: But the C/C++ keywords are all English, too; lint tools only accept English, and so it wouldn't seem unreasonable to only accept En

Re: internal fn pretty printing

On 09/27/2016 12:58 PM, Nathan Sidwell wrote: In working on some new code I got sufficiently frustrated to implement pretty printing on internal function discriminators, as I think one of you suggested a while back. With this patch we get: .data_dep.2 = UNIQUE (OACC_FORK, .data_dep.2, -1); ra

Re: Implement -Wimplicit-fallthrough (version 9)

On 09/27/2016 01:51 PM, Marek Polacek wrote: But the C/C++ keywords are all English, too; lint tools only accept English, and so it wouldn't seem unreasonable to only accept English keywords in the comments. And in any case, I don't see how a compiler can be expected to be able to parse non-Engl

Re: [PATCH RESEND 2/2] Extend -falign-FOO=N to N[,M[,N2[,M2]]]

On 09/26/2016 09:08 PM, Denys Vlasenko wrote: +@gccoptlist{-faggressive-loop-optimizations @gol +-falign-functions[=@var{n}[,@var{m},[@var{n}[,@var{m} @gol +-falign-jumps[=@var{n}[,@var{m}]] @gol +-falign-labels[=@var{n}[,@var{m}]] -falign-loops[=@var{n}[,@var{m}]] @gol @itemx -falign-fun

Re: Implement -Wimplicit-fallthrough (version 9)

On 09/27/2016 01:09 PM, Richard Biener wrote: On Tue, Sep 27, 2016 at 1:06 PM, Eric Botcazou wrote: The accepted style is already very permissive, we don't allow just one spelling as various lint tools. Well, it cannot even handle the variations of a single codebase, GCC itself, so I'm afraid

Re: [Patch, reload, tentative, PR 71627] Tweak conditions in find_valid_class_1

On 09/16/2016 09:02 PM, Senthil Kumar Selvaraj wrote: Does this make sense? I ran a reg test for the avr target with a slightly older version of this patch, it did not show any regressions. If this is the right fix, I'll make sure to run reg tests on x86_64 after backporting to a gcc vers

Re: [PATCH][regrename][sel-sched] Fix bogus use of HARD_FRAME_POINTER_REGNUM (was: Fix arm bootstrap)

On 09/26/2016 04:34 PM, Kyrill Tkachov wrote: Hi all, This patch implements the minimal fixes for the issues that https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01547.html was supposed to address as suggested by Alexander. Bootstrapped and tested on aarch64-none-linux-gnu and arm-none-linux-gnue

OpenACC data clause syntax question/patch

While trying to get the following benchmarks to run: https://codesign.llnl.gov/lulesh.php I came across some cases where the code and the compiler differed in its interpretation of the OpenACC spec. Specifically, this occurs for acc data clauses with arrays, like: #pragma acc data copyin(a[

Re: [PATCH] Use CONSTRUCTOR_NELTS macro some more

On 09/22/2016 10:07 PM, Jakub Jelinek wrote: I've noticed lots of vec_safe_length (CONSTRUCTOR_ELTS (...)) uses in the sources, which IMHO are less readable than the much more often used CONSTRUCTOR_NELTS (...) macro that does the same thing. Bootstrapped/regtested on x86_64-linux and i686-linux

Re: Make regcprop to eliminate noop moves better

On 09/22/2016 01:48 PM, Jan Hubicka wrote: * postreload.c (reload_cse_simplify): Also accept USE in noop move patterns. diff --git a/gcc/postreload.c b/gcc/postreload.c index 61c1ce8..4f3a526 100644 --- a/gcc/postreload.c +++ b/gcc/postreload.c @@ -153,7 +153,8 @@ reload_cse_sim

Re: [PATCH] Fix JUMP_LABEL documentation

On 09/20/2016 08:51 PM, Segher Boessenkool wrote: * doc/rtl.texi (JUMP_LABEL): Document RETURN and SIMPLE_RETURN values. Ok, thanks. Bernd

Re: [RFC][IRA]Initialize ira_use_lra_p early by moving the initialization into ira_init_once ().

On 09/21/2016 01:46 PM, Renlin Li wrote: * ira.c (ira): Move ira_use_lra_p initialization code to ... (ira_init_once): Here. LGTM. Bernd

Re: [PATCHv3, resent] Add a warning for suspicious use of conditional expressions in boolean context

On 09/21/2016 01:09 AM, Trevor Saunders wrote: I thought I remember discussing this macro with you, but see what was checked in I'll believe I'm thinking of something similar but different. I think this here was an earlier patch and the one we were discussing recently was the other macro with

Re: Register numbers in RTL dumps (was Re: [PATCH 0/9] RFC: selftests based on RTL dumps)

On 09/20/2016 05:20 PM, Jeff Law wrote: On 09/20/2016 08:34 AM, Bernd Schmidt wrote: (reg/f:DI v1 virtual-stack-vars) this. Doesn't the same apply to the number of virtual stack regs? Those are in the same array as pseudos. So ISTM we prefix in the dump, but do adjustment of the n

Re: [PATCHv3, resent] Add a warning for suspicious use of conditional expressions in boolean context

On 09/20/2016 05:18 PM, Jeff Law wrote: I assume HARD_FRAME_POINTER_REGNUM is never zero. It could be zero. It's just a hard register number. No target has the property that its hard frame pointer register is 0 though :-) git blame to the rescue. The current state comes from one of tbsaunde'

Re: Register numbers in RTL dumps (was Re: [PATCH 0/9] RFC: selftests based on RTL dumps)

On 09/20/2016 04:32 PM, David Malcolm wrote: To summarize so far: you want every pseudo to have its regno dumped with a 'p' prefix, and renumber them on dump (and then on load). OK. Renumbering is not helpful because it interferes with the view you have in the debugger. So, IMO just a prefix,

Re: [PATCH 0/8] make next_*_insn take rtx_insn * arguments

On 09/20/2016 01:16 AM, Segher Boessenkool wrote: On Mon, Sep 19, 2016 at 06:07:46PM -0400, Trevor Saunders wrote: - JUMP_LABEL can be a return which is not an insn. That also seems like something that should be improved at some point. The JUMP_LABEL field within a JUMP_INSN? That sounds

Re: [PATCH][simplify-rtx] (GTU (PLUS a C) (C - 1)) --> (LTU a -C)

On 09/19/2016 04:43 PM, Kyrill Tkachov wrote: Ok? Sure. Bernd

Re: Do not drom MEM_EXPR when accessing structure fields

On 09/18/2016 02:51 PM, Jan Hubicka wrote: to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE); - - /* If the field has a mode, we want to access it in the -field's mode, not the computed mode. -If a MEM has VOIDmode (external with incomplete type), -

Re: [PATCH 0/9] RFC: selftests based on RTL dumps

On 09/16/2016 11:12 PM, David Malcolm wrote: There are some interrelated questions here: (a) where do the dumps live? (string fragments embedded in the source file vs external files) (b) -fself-test vs DejaGnu tests that use a real frontend. In the latter case, is the frontend "rtl1", or an exte

Re: [PATCH][simplify-rtx] (GTU (PLUS a C) (C - 1)) --> (LTU a -C)

On 09/16/2016 10:40 AM, Kyrill Tkachov wrote: 2016-09-16 Kyrylo Tkachov * simplify-rtx.c (simplify_relational_operation_1): Add transformation (GTU (PLUS a C) (C - 1)) --> (LTU a -C). 2016-09-16 Kyrylo Tkachov * gcc.target/aarch64/gtu_to_ltu_cmp_1.c: New test. Ok. Don't kn

Re: [PATCH 0/8] make next_*_insn take rtx_insn * arguments

On 09/16/2016 12:10 PM, Trevor Saunders wrote: ok, going through all the casts added here I see the following reasons for them. - in md files operands is a array of rtx, we should probably have a different way to pass insns to the C code here. That seems worth investigating incrementally.

Re: [PATCH] Optimize strchr (s, 0) to strlen

On 09/15/2016 03:38 PM, Wilco Dijkstra wrote: __rawmemchr is not the fastest on any target I tried, including x86, Interesting. Care to share your test program? I just looked at the libc sources and strlen/rawmemchr are practically identical code so I'd expect any difference to be lost in the

Re: [PATCH 0/8] make next_*_insn take rtx_insn * arguments

On 09/14/2016 09:21 PM, tbsaunde+...@tbsaunde.org wrote: Basically $subject. First change variable's type to rtx_insn * where possible. Then change the functions and fixup callers where it is still necessary to cast. #2, #4 and #8 look good and can be applied if they work independently of th

Re: Patch ping

On 09/14/2016 11:47 PM, Jakub Jelinek wrote: http://gcc.gnu.org/ml/gcc-patches/2016-09/msg00088.html - PR77425 - fix UB in sd_iterator_cond Ok. Bernd

Re: [PATCH 5/9] regrename: Don't run if function was separately shrink-wrapped

On 09/14/2016 03:55 PM, Segher Boessenkool wrote: On Wed, Sep 14, 2016 at 03:08:21PM +0200, Bernd Schmidt wrote: The data that was posted showed a code size decrease on a number of targets. I'm really not sure where this irrational hate for regrename comes from. It increases the numb

Re: [PATCH 5/9] regrename: Don't run if function was separately shrink-wrapped

On 09/14/2016 03:04 PM, Segher Boessenkool wrote: Then rs6000 (and many other ports probably) will just turn it off again. It is actively harmful. The data that was posted showed a code size decrease on a number of targets. I'm really not sure where this irrational hate for regrename comes fr

Re: [PATCH] fix-it hints for warn_uninit

On 09/14/2016 02:45 AM, David Malcolm wrote: In combination with -fdiagnostics-generate-patch this can generate output like this: --- ../../src/gcc/testsuite/c-c++-common/fix-missing-initializer-1.c +++ ../../src/gcc/testsuite/c-c++-common/fix-missing-initializer-1.c @@ -2,7 +2,7 @@ in

Re: [PATCH 0/9] RFC: selftests based on RTL dumps

On 09/13/2016 01:15 PM, Bernd Schmidt wrote: On 09/12/2016 08:57 PM, David Malcolm wrote: I'm not sure I follow - this sounds like a dedicated target for selftesting. Would it be a separate configuration i.e. something like: ../src/configure --target=rtl-selftest or somesuch? The

Re: RFC: PATCH to consider MAX_OFILE_ALIGNMENT for targetm.absolute_biggest_alignment

On 09/13/2016 04:24 PM, Jason Merrill wrote: But we could define TARGET_ABSOLUTE_BIGGEST_ALIGNMENT on nvptx instead of on x86; is this OK? That's what I had in mind. It would be good if Thomas or Nathan could give this patch a spin, I'm not currently really set up for it. But it looks like a

Re: [PATCH 0/9] RFC: selftests based on RTL dumps

On 09/12/2016 08:57 PM, David Malcolm wrote: I'm not sure I follow - this sounds like a dedicated target for selftesting. Would it be a separate configuration i.e. something like: ../src/configure --target=rtl-selftest or somesuch? The way I imagine it working, the top-level Makefile would

Re: RFC: PATCH to consider MAX_OFILE_ALIGNMENT for targetm.absolute_biggest_alignment

On 09/12/2016 08:58 PM, Jason Merrill wrote: TARGET_ABSOLUTE_BIGGEST_ALIGNMENT is documented to be the largest alignment possible for any type or variable, and defaults to BIGGEST_ALIGNMENT. But MAX_OFILE_ALIGNMENT is typically much larger than BIGGEST_ALIGNMENT, and is documented as the limit f

Re: [PATCH 1/3] Put a TARGET_LRA_P into every target

On 09/13/2016 12:22 AM, Segher Boessenkool wrote: This patch adds a TARGET_LRA_P (defined to hook_bool_void_false) to every target that didn't yet override the hook. No functional change. This patch series makes very little sense to me. Adding 35 new instances of a hook definition so you can

Re: [PATCH 0/9] RFC: selftests based on RTL dumps

In general, it's functionality that I would very much like to have (although maybe it's less useful these days now that the rtl side is fairly static). I think there's not much sense looking too deeply at the individual patches yet; we need to first figure out what we would really like this to

Re: [PATCH, i386] Spellcheck hints for the i386 backend option handling (PR middle-end/77475, take 2, generic part)

On 09/06/2016 10:36 PM, Jakub Jelinek wrote: +/* Helper function for listing valid choices and hint for misspelled + value. CANDIDATES is a vector containing all valid strings, + STR is set to a heap allocated string that contains all those + strings concatenated, separated by spaces, and

Re: [DOC] Boolean -> boolean changes

On 09/10/2016 12:56 PM, Marek Polacek wrote: 2016-09-10 Marek Polacek * doc/extend.texi: Use lowercase "boolean". * doc/invoke.texi: Likewise. * doc/md.texi: Likewise. * target.def: Likewise. * doc/tm.texi: Regenerated. Ok. Bernd

Re: [PATCH v2 0/9] Separate shrink-wrapping

On 09/09/2016 10:56 PM, Segher Boessenkool wrote: On Fri, Sep 09, 2016 at 12:57:32PM -0600, Jeff Law wrote: I think the lack of test coverage is something we'll want to address. Building and running the compiler, the various target libraries, and the testsuite is more than enough coverage for

Re: [PATCH 1/9] separate shrink-wrap: New command-line flag, status flag, hooks, and doc

On 09/08/2016 07:20 PM, Jeff Law wrote: On 08/29/2016 03:31 AM, Bernd Schmidt wrote: How do these actually know where to save/restore registers? The frame pointer may have been eliminated, and SP isn't necessarily constant during the function. Seems like you'd have to calculate CFA

Re: Make max_align_t respect _Float128 [version 2]

On 09/08/2016 01:21 AM, Paul Eggert wrote: Sure, attached. On Fedora 24 x86-64 (GCC 6.1.1 20160621, valgrind 3.11.0), when I compile with "gcc -O2 flexouch.c" and run with "valgrind ./a.out", valgrind complains "Invalid read of size 2". This is because GCC compiles "p->d[0] == 2 && p->d[1] == 3"

Re: [Patch libgcc] Enable HCmode multiply and divide (mulhc3/divhc3)

On 09/07/2016 06:05 PM, James Greenhalgh wrote: Hi, This patch arranges for half-precision complex multiply and divide routines to be built if __LIBGCC_HAS_HF_MODE__. This will be true if the target supports the _Float16 type. OK? Ok, but please see Joseph's patch from today: I think you pr

Re: Correct libgcc complex multiply excess precision handling

On 09/07/2016 11:48 PM, Joseph Myers wrote: libgcc complex multiply is meant to eliminate excess precision from certain internal values by forcing them to memory in exactly those cases where the type has excess precision. But in https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01894.html I accident

Re: [PATCH][v3] GIMPLE store merging pass

On 09/07/2016 10:19 AM, Richard Biener wrote: On Tue, 6 Sep 2016, Jakub Jelinek wrote: If you want a 64-bit store, you'd need to merge the two, and that would be even more expensive. It is a matter of say: movl $0x12345678, (%rsp) movl $0x09abcdef, 4(%rsp) vs. movabs

Re: [DOC] Boolean -> boolean changes

On 09/06/2016 11:19 AM, Marek Polacek wrote: As discussed , this patch makes the Boolean -> boolean change in our doc/ directory. Ok for trunk? Yes, thanks. Bernd

Re: Make max_align_t respect _Float128 [version 2]

On 09/06/2016 11:11 AM, Florian Weimer wrote: I think this change is only safe because nothing relies on it. max_align_t is a committee invention with no actual users. I tried to verify that and ran grep over all the packages in /usr/portage/distfiles. That did get a number of matches, fairly

Re: C/C++ PATCH for c/77423 (bogus warning with -Wlogical-not-parentheses)

On 09/05/2016 12:52 PM, Marek Polacek wrote: On Mon, Sep 05, 2016 at 12:35:13PM +0200, Bernd Schmidt wrote: On 09/02/2016 05:13 PM, Marek Polacek wrote: diff --git gcc/doc/invoke.texi gcc/doc/invoke.texi index 87da1f1..38d55d4 100644 --- gcc/doc/invoke.texi +++ gcc/doc/invoke.texi @@ -5437,8

Re: C/C++ PATCH for c/77423 (bogus warning with -Wlogical-not-parentheses)

On 09/02/2016 05:13 PM, Marek Polacek wrote: diff --git gcc/doc/invoke.texi gcc/doc/invoke.texi index 87da1f1..38d55d4 100644 --- gcc/doc/invoke.texi +++ gcc/doc/invoke.texi @@ -5437,8 +5437,8 @@ if (a < 0 && a < 0) @{ @dots{} @} @opindex Wlogical-not-parentheses @opindex Wno-logical-not-parent

Re: [PATCH, rtl-optimization]: Fix PR77452, ICE: in plus_constant, at explow.c

On 09/04/2016 02:12 PM, Uros Bizjak wrote: As shown in the PR [1], combine is able to simplify lowpart CONST_VECTOR constant pool reference to its inner-mode reference. However, plus_constant was not able to extract the constant from narrowed access. Attached patch teaches plus_constant how to h

Re: [PATCH] Improvements to typed_splay_tree (v2)

On 09/01/2016 03:01 AM, David Malcolm wrote: On Wed, 2016-08-31 at 16:12 +0200, Bernd Schmidt wrote: Looks ok otherwise. Thanks. Here's a revised version; I moved the "struct closure" into the class itself. Successfully bootstrapped®rtested on x86_64-pc-linux-gnu. OK fo

Re: [PATCH 2/4] Improvements to typed_splay_tree

On 08/24/2016 03:28 AM, David Malcolm wrote: +/* Helper type for typed_splay_tree::foreach. */ + +template +struct closure Is this in the global namespace? If so, something more specific than "closure" might be more appropriate. Or move the struct into the typed_splay_tree class definition.

Re: [PATCH] selftest.c: avoid explicit "selftest::" qualifiers

On 08/31/2016 02:31 AM, David Malcolm wrote: The following follow-up patch removes them, moving the "namespace selftest {" to the top of the file so it covers everything. LGTM. Bernd

Re: [PATCH] C: fixits for modernizing structure member designators

On 08/30/2016 04:38 PM, David Malcolm wrote: In conjunction with the not-yet-in-trunk -fdiagnostics-generate-patch, this can generate patches like this: --- modernize-named-inits.c +++ modernize-named-inits.c @@ -16,7 +16,7 @@ /* Old-style named initializers. */ struct foo old_style_f = { -

Re: [PATCH 1/4] selftest: split out named_temp_file from temp_source_file

On 08/25/2016 03:13 AM, David Malcolm wrote: Split out a new base class for temp_source_file, named_temp_file, moving the deletion to the base class dtor, so that we can write out temporary files in other ways in selftests. gcc/ChangeLog: * selftest.c (selftest::named_temp_file::named_te

Re: [PATCH 1/9] separate shrink-wrap: New command-line flag, status flag, hooks, and doc

On 08/01/2016 03:42 AM, Segher Boessenkool wrote: +@deftypefn {Target Hook} void TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS (sbitmap) +Emit prologue insns for the components indicated by the parameter. +@end deftypefn + +@deftypefn {Target Hook} void TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS

Re: [PATCH] report supported function classes correctly on *-musl

On 07/20/2016 03:39 PM, Szabolcs Nagy wrote: 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

Re: [PATCH] disable ifunc on *-musl by default

On 07/20/2016 03:37 PM, Szabolcs Nagy wrote: 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. Ok I suppose? I'm assumi

Re: [PATCH] selftest.h: mark failure functions with ATTRIBUTE_NORETURN.

On 08/26/2016 08:20 PM, David Malcolm wrote: Is this revised version OK for trunk? LGTM. Bernd

Re: [PATCH] selftest.h: mark failure functions with "noreturn"

On 08/26/2016 06:05 PM, David Malcolm wrote: selftest::fail and selftest::fail_formatted call abort. Marking them as "noreturn" can help eliminate false warnings about unreachable code in selftests. Successfully bootstrapped®rtested on x86_64-pc-linux-gnu. OK for trunk? Don't we want to wrap

Re: [PATCH 3/3] make stack_slot_list a vec

On 08/26/2016 06:03 PM, Trevor Saunders wrote: yeah, it was just from being overly careful to not change behavior, but that's silly we can always revert if it turns out to break something. Not silly at all - it's a good mindset to have. But in cases where the order doesn't matter I think it's

Re: [PATCH v2 0/9] Separate shrink-wrapping

On 08/26/2016 04:50 PM, Segher Boessenkool wrote: The head comment starts with +/* Separate shrink-wrapping + + Instead of putting all of the prologue and epilogue in one spot, we + can put parts of it in places where those components are executed less + frequently. and that is the long a

Re: [PATCH v2 0/9] Separate shrink-wrapping

On 08/26/2016 03:48 PM, David Malcolm wrote: I'm nervous about the build_random_cfg function: randomness in selftests seems like a double-edged sword. On the one hand, we can use it to fuzz-test an optimization to rapidly gain a lot of coverage. On the other hand, does every host generate the s

Re: [PATCH v2 0/9] Separate shrink-wrapping

On 08/01/2016 03:42 AM, Segher Boessenkool wrote: This is the second version. Concern was renamed to component, and all other comments were addressed (I hope). Not really, I'm afraid. There still seems to be no detailed explanation of the algorithm. Instead, there is a vague outline (which sh

Re: [PATCH 1/3] haifa-sched.c: make ready_list an auto_vec

On 08/25/2016 08:50 AM, tbsaunde+...@tbsaunde.org wrote: From: Trevor Saunders gcc/ChangeLog: 2016-08-25 Trevor Saunders * haifa-sched.c (fix_recovery_deps): Make ready_list a vector. The subject of the mail scared me, but it looks like this just deals with a local variable in

Re: [PATCH 3/3] make stack_slot_list a vec

On 08/25/2016 08:50 AM, tbsaunde+...@tbsaunde.org wrote: @@ -2626,8 +2626,10 @@ unshare_all_rtl_1 (rtx_insn *insn) This special care is necessary when the stack slot MEM does not actually appear in the insn chain. If it does appear, its address is unshared from all else at that

Re: [PATCH 2/3] make forced labels a vec

On 08/25/2016 08:50 AM, tbsaunde+...@tbsaunde.org wrote: + FOR_EACH_VEC_SAFE_ELT_REVERSE (forced_labels, i, insn) + make_label_edge (edge_cache, bb, insn, EDGE_ABNORMAL); All of these look like they'd be perfectly fine as a normal FOR_EACH_VEC_SAFE_ELT, and it would b

Re: [PATCH 0/4] Applying fix-its on behalf of the user to their code

On 08/24/2016 03:28 AM, David Malcolm wrote: (B) -fdiagnostics-apply-fixits, which writes back the changes to the input files. That sounds really scary, there's no way I'd personally ever enable something like this. Do we have any data about what percentage of fixits actually correctly ident

Re: [PATCH] remove HARD_FRAME_POINTER_IS_ARG_POINTER macro

On 08/20/2016 07:07 PM, tbsaunde+...@tbsaunde.org wrote: From: Trevor Saunders Hi, its kind of silly, and this allows us to remove a few more #ifdefs. #if FRAME_POINTER_REGNUM != ARG_POINTER_REGNUM -#if HARD_FRAME_POINTER_IS_ARG_POINTER +#if HARD_FRAME_POINTER_REGNUM == ARG_POINTER_REGNUM

Re: protected alloca class for malloc fallback

On 08/09/2016 03:17 PM, Aldy Hernandez wrote: On 08/05/2016 01:55 PM, Richard Biener wrote: Hi Richard. Please don't use std::string. For string building you can use obstacks. Alright let's talk details then so I can write things up in a way you approve of. Take for instance simple uses

Re: [Patch, tentative, reload] Make push_reload work with more types of subregs?

On 08/08/2016 05:26 PM, Senthil Kumar Selvaraj wrote: I picked out the commit where you'd added SYMBOL_REF handling (rev #190252), and patched that with the below code. Bootstrapped and regtested on x86_64-pc-linux - the results were identical with and without the patch. Is this good enough for

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te

On 08/04/2016 04:49 PM, Thomas Schwinge wrote: Global Reviewers are welcome to review OpenACC/OpenMP/offloading patches. But that doesn't help if that's then not happening in reality. (With the exception of Bernd, who then did review such patches for a while, but also seems to have stopped with

Re: [PATCH] Fix wrong code on aarch64 due to paradoxical subreg

On 08/02/2016 06:46 PM, Segher Boessenkool wrote: On Tue, Aug 02, 2016 at 09:21:34AM -0600, Jeff Law wrote: However I think there are more paradoxical subregs generated all over, but the aarch64 insv code pattern did trigger more hidden bugs than any other port. It is certainly unfortunate that

Re: [PATCH] nvptx: do not implicitly enable -ftoplevel-reorder

On 08/01/2016 10:44 PM, Joseph Myers wrote: On Fri, 22 Jul 2016, Bernd Schmidt wrote: What's the motivation for supporting -fno-toplevel-reorder anyway? That's practically just a legacy mode as far as I know. It's for code that uses toplevel asms in ways for which it mat

Re: [libiberty] fix unbounded alloca in make_relative_prefix_1

On 07/29/2016 05:07 PM, Aldy Hernandez wrote: There is currently only one use, but I was thinking that perhaps if there were other alloca uses added later (I hope not), that they could all use the same macro. But I am more than happy to place this definition it in it's only use file for now, if t

Re: [libiberty] fix unbounded alloca in make_relative_prefix_1

On 07/29/2016 02:30 PM, Aldy Hernandez wrote: +/* Max number of alloca bytes per call before we must switch to malloc. + + ?? Swiped from gnulib's regex_internal.h header. Is this actually + the case? This number seems arbitrary, though sane. + + The OS usually guarantees only one guard p

Re: [Patch, tentative, reload] Make push_reload work with more types of subregs?

On 07/28/2016 09:33 AM, Senthil Kumar Selvaraj wrote: Is there a reason why only REG and SYMBOL_REFs get valid subreg_in_class? I tried extending it handle constants and PLUS expressions, and it fixes PR 71873. It also fixes a another bug that was a work around for the reload failure (PR

Re: C PATCH for c/71583 (ICE with bogus compound literal)

On 07/28/2016 03:19 PM, Marek Polacek wrote: Since r157233, build_compound_literal will return error_mark_node for erroneous initializers of compound literals. This caused an ICE in c_parser_postfix_expression_after_paren_type because the code dealing with evaluating variably modified types wasn

Re: C PATCH for c/71574 (ICE with alloc_align attribute)

On 07/28/2016 03:26 PM, Marek Polacek wrote: Many attributes that accept integer constant as a parameter call default_conversion for such constants to perform the usual arithmetic conversions. The call to default_conversion is always guarded so as to prevent a NULL_TREE, an IDENTIFIER_NODE, or a

Re: [PATCH] nvptx: do not implicitly enable -ftoplevel-reorder

On 07/22/2016 05:19 PM, Alexander Monakov wrote: I hope I've satisfactorily explained the failures you've pointed out (thanks for the data). I think I should leave the choice of what to do next (revert the patch or leave it in and install fixups where appropriate) up to you? What's the motivat

Re: Implement -Wimplicit-fallthrough: the rest

On 07/22/2016 01:15 PM, Jakub Jelinek wrote: @@ -32335,6 +32341,7 @@ rs6000_handle_altivec_attribute (tree *node, case V4SImode: case V8HImode: case V16QImode: case V4SFmode: case V2DImode: case V2DFmode: result = type; + gcc_fallthrough (); default: brea

Re: [Re: RFC: Patch 1/2 v3] New target hook: max_noce_ifcvt_seq_cost

On 07/20/2016 06:39 PM, James Greenhalgh wrote: On Wed, Jul 20, 2016 at 01:41:39PM +0200, Bernd Schmidt wrote: How about wrapping the param value into COSTS_N_INSNS, to make the value of the param less dependent on compiler internals? I did consider this, but found it hard to word for the

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

On 07/21/2016 01:16 PM, Jakub Jelinek wrote: On Thu, Jul 21, 2016 at 11:04:48AM +, Bernd Edlinger wrote: bool +gimple_alloca_call_p (const gimple *stmt) +{ + tree fndecl; + + if (!is_gimple_call (stmt)) +return false; + + fndecl = gimple_call_fndecl (stmt); + if (fndecl && DECL_BU

Re: [PATCH]: Introduce HOST_WIDE_INT_0{,U}

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

Re: Merge switch statements in tree-cfgcleanup

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

Re: [PATCH]: Use HOST_WIDE_INT_{,M}1{,U} some more

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

Re: [Re: RFC: Patch 1/2 v3] New target hook: max_noce_ifcvt_seq_cost

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.texi: Regenerate. * targhooks.h (default_max_noce_ifcvt_seq_cost)

Re: [PATCH] Avoid invoking ranlib on libbackend.a

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 entirely explicit ack, I'll add mine. Thank you for doing this.

Re: [PATCH 8/9] shrink-wrap: shrink-wrapping for separate concerns

On 07/19/2016 05:35 PM, Segher Boessenkool wrote: On Tue, Jul 19, 2016 at 04:49:26PM +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 th

<    1   2   3   4   5   6   7   8   9   10   >