Re: [PATCH] Add linker plugin API for processing plugin-added input files

On Thu, Sep 21, 2017 at 5:29 PM, Cary Coutant wrote: >> 2017-09-21 Stephen Crane >> >> * plugin-api.h: Add new hook to the plugin transfer vector to >> support assigning plugin-generated sections to unique output >> segments. >>

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

2017-09-21 22:38 GMT+02:00 Steve Kargl : > On Thu, Sep 21, 2017 at 09:10:42AM +0200, Janus Weil wrote: >> Attached is an updated patch, where I'm adding -fdefault-real-10 >> according to Steve's suggestion. As with -fdefault-real-8 and >> -fdefault-real-16, I'm

Re: [PATCH] [i386, libgcc] PR 82196 -mcall-ms2sysv-xlogues emits wrong AVX/SSE MOV

On 09/21/2017 05:18 PM, Daniel Santos wrote: > So libgcc doesn't use a config.in. :( Scratch that, I forgot that we're using gcc/config.in via auto-host.h.  So I only have to add this to gcc/configure.ac and it will be available for my libgcc header -- this is what I used to sniff out support for

Re: [PATCH] Add linker plugin API for processing plugin-added input files

> 2017-09-21 Stephen Crane > > * plugin-api.h: Add new hook to the plugin transfer vector to > support assigning plugin-generated sections to unique output > segments. > (ld_plugin_register_new_input): New hook. > (ld_plugin_tag): Add

[PATCH] Add linker plugin API for processing plugin-added input files

I'm looking to extend the linker plugin API to allow linker plugins the chance to assign sections to segments for sections in plugin-generated files. Currently the linker does not give the plugin the opportunity to call the unique_segment_for_sections interface for files generated by a plugin,

Re: [PATCH][RFC] Radically simplify emission of balanced tree for switch statements.

On 20 September 2017 17:00:13 CEST, Jeff Law wrote: >On 09/20/2017 01:24 AM, Martin Liška wrote: > >> >> Hello. >> >> Thank you Jeff for very verbose explanation what's happening. I'm >planning to do >> follow-up of this patch that will include clustering for bit-tests >and

[PATCH version 4, rs6000] Add builtins to convert from float/double to int/long using current rounding mode

GCC maintainers: The following patch has been updated to address Segher's comments. The patch. The new BU_FP_MISC_1 macro has been changed so gcc will gracefully exit when the command line option -msoft-float is used. I have tested the patch on powerpc64le-unknown-linux-gnu (Power 8 LE). I

Re: [PATCH] Rename existing insn_cost to insn_sched_cost

On Thu, Sep 21, 2017 at 10:36:48PM +0100, Richard Sandiford wrote: > Segher Boessenkool writes: > > haifa-sched exports an insn_cost function, but it is only used in a > > few places and specialised to scheduling. This patch renames it to > > insn_sched_cost. > > > >

Re: [PATCH] [i386, libgcc] PR 82196 -mcall-ms2sysv-xlogues emits wrong AVX/SSE MOV

On 09/21/2017 11:14 AM, Rainer Orth wrote: > Hi Daniel, > >> On 09/19/2017 01:58 AM, Jakub Jelinek wrote: >>> What can be done in libgcc is detect in configure whether the assembler >>> supports AVX, and if not, provide some alternative (e.g. because the insns >>> are always the same, you could

[committed] Fix stack-clash protection failures for x86 Solaris

This fixes two issues that Rainer ran into on the x86 solaris port. The x86 Solaris port handles the frame pointer differently than other x86 ports. It requires frame pointers in cases that others do not -- it's a lot like aarch64 and just needed a trivial update to handle x86 solaris specially

Re: [PATCH] Rename existing insn_cost to insn_sched_cost

Segher Boessenkool writes: > haifa-sched exports an insn_cost function, but it is only used in a > few places and specialised to scheduling. This patch renames it to > insn_sched_cost. > > Okayed by Jeff at https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00202.html, >

[PATCH, rs6000] folding of vector stores in GIMPLE

Hi, Folding of vector stores in GIMPLE. - Add code to handle gimple folding for the vec_st (vector store) builtins. - Remove the now obsoleted folding code for vec_st from rs6000-c-c. There are two spots that I could use some feedback on. First - An early exit remains in place

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

On Thu, Sep 21, 2017 at 09:10:42AM +0200, Janus Weil wrote: > Attached is an updated patch, where I'm adding -fdefault-real-10 > according to Steve's suggestion. As with -fdefault-real-8 and > -fdefault-real-16, I'm choosing to set the double kind to 16 in this > case. Also I'm renaming

Re: [PATCH] tree-sra: fix compare_access_positions qsort comparator

Alexander Monakov writes: > diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c > index 163b7a2d03b..4f9a8802aeb 100644 > --- a/gcc/tree-sra.c > +++ b/gcc/tree-sra.c > @@ -1542,19 +1542,17 @@ compare_access_positions (const void *a, const void > *b) > && TREE_CODE

[PING][PATCH] Output DIEs for outlined OpenMP functions in correct lexical scope

Ping. On Mon, 7 Aug 2017 17:51:38 -0700 Kevin Buettner wrote: > On Wed, 10 May 2017 17:24:27 +0200 > Jakub Jelinek wrote: > > > What I don't like is that the patch is inconsistent, it sets DECL_CONTEXT > > of the child function for all kinds of outlined

Re: Backtrace library [3/3]

On 21.09.2017 17:50, Ian Lance Taylor via gcc-patches wrote: > On Thu, Sep 21, 2017 at 4:52 AM, Thomas Schwinge > wrote: >> >> On Fri, 14 Sep 2012 14:20:08 -0700, Ian Lance Taylor wrote: [libbacktrace] >> >>> I won't commit for a day or two in case

libbacktrace patch committed: Fix uninitialized field

I somehow failed to initialize the exe_filename field of phdr_data, which most likely led to PR 82284. Bootstrapped and ran libbacktrace tests for this obvious fix. Committed to mainline. Ian 2017-09-21 Ian Lance Taylor PR go/82284 * elf.c (backtrace_initialize): Set

Re: [Patch, fortran] Bug fixes, including regressions, for the associate construct

Dear Jerry, Thanks! Committed as revision 253077. Cheers Paul On 21 September 2017 at 01:52, Jerry DeLisle wrote: > On 09/20/2017 09:45 AM, Paul Richard Thomas wrote: >> In the last update to the Parameterized Derived Types implementation, >> I fixed PR60483 as a side

[PATCH, rs6000] testcase coverage for vector store builtins

Hi, Add testcase coverage for the vec_st (vector store) intrinsic builtins. Tested across power platforms (p6 and newer). OK for trunk? Thanks, -Will [gcc/testsuite] 2017-09-21 Will Schmidt * gcc.target/powerpc/fold-vec-st-char.c: New.

Re: [committed][PATCH] Stack clash protection patch 04/08 - V4

On 09/21/2017 02:38 AM, Rainer Orth wrote: > Jeff Law writes: > >> This patch introduces the x86 stack clash protected prologue support as >> well as the tests. I believe the only change since V3 was the more >> aggressive introduction of scheduling barriers. It also enables

[PATCH] tree-sra: fix compare_access_positions qsort comparator

Hi, The compare_access_positions qsort comparator lacks transitivity, although somewhat surprisingly this issue didn't manifest on 64-bit x86 bootstraps. The first invalid comparison step is here (tree-sra.c:1545): /* Put the integral type with the bigger precision first. */ else if

Re: PING^2: Fwd: SSA range class and removal of VR_ANTI_RANGEs

On September 20, 2017 1:10:25 AM GMT+02:00, Jeff Law wrote: >On 07/26/2017 05:20 AM, Richard Biener wrote: >> On Tue, Jul 25, 2017 at 4:50 PM, Andrew MacLeod >wrote: >>> On 07/25/2017 03:12 AM, Richard Biener wrote: On Fri, Jul 21, 2017 at 9:30 PM,

Re: [PATCH] C++: underline parameters in mismatching function calls

On 09/20/2017 01:52 PM, David Malcolm wrote: When we have a type mismatch in a C++ function call, e.g. extern int callee (int one, const char *two, float three); int caller (int first, int second, float third) { return callee (first, second, third); } we currently emit something

Re: [committed][PATCH] Stack clash protection patch 04/08 - V4

On 09/21/2017 02:38 AM, Rainer Orth wrote: > Jeff Law writes: > >> This patch introduces the x86 stack clash protected prologue support as >> well as the tests. I believe the only change since V3 was the more >> aggressive introduction of scheduling barriers. It also enables

Re: [PATCH] C++: underline parameters in mismatching function calls

On Wed, Sep 20, 2017 at 3:52 PM, David Malcolm wrote: > + /* If we have a method, then DECL_ARGUMENTS begins with "this"; > + increment ARGNUM to skip it. */ > + if (TREE_CODE (TREE_TYPE (fndecl)) == METHOD_TYPE) > +argnum++; > + > + /* Locate param by index

Re: [PATCH] C++: underline parameters in mismatching function calls

On 09/20/2017 12:52 PM, David Malcolm wrote: When we have a type mismatch in a C++ function call, e.g. whereas underlining the mismatching things would make the messages easier to comprehend: test.c: In function 'int caller(int, int, float)': test.c:5:38: error: invalid conversion from

Re: [PATCH] [i386, libgcc] PR 82196 -mcall-ms2sysv-xlogues emits wrong AVX/SSE MOV

Hi Daniel, > On 09/19/2017 01:58 AM, Jakub Jelinek wrote: >> What can be done in libgcc is detect in configure whether the assembler >> supports AVX, and if not, provide some alternative (e.g. because the insns >> are always the same, you could just code them as .byte or something similar). >> >>

[demangler PATCH]: eliding template return types

Guys in cc: you've looked at demangling sometime in the past, so may have an opinion. As alluded to in https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01482.html we display the return type of template functions containing local objects. This gets easily confused with the return type of the

[demangler PATCH]: Revert and update generic lambda demangling

My recent change to generic lambda demangling was incorrect. It wrapped the function type inside the local name, which allowed the printer to see the correct set of template parameters (and not recurse). Except there was a hack to not do that at the outer most level. but that still ends up

Re: Backtrace library [3/3]

On Thu, Sep 21, 2017 at 4:52 AM, Thomas Schwinge wrote: > > On Fri, 14 Sep 2012 14:20:08 -0700, Ian Lance Taylor wrote: >>> [libbacktrace] > >> I won't commit for a day or two in case anybody sees a >> problem in the implementation. > > Eventually got

Remove kludge in bit_from_pos

The kludge was added by Richard G. and me to help Ada when Richard was trying to remove the TYPE_IS_SIZETYPE flag from the middle-end 5 years ago, but it's not correct as witnessed by the attached testcase; and it's obsolete anyway. Tested on x86_64-suse-linux, applied on the mainline as

[PATCH][GRAPHITE] Strip down dominator recompute, checking and friends

The following is a quick attempt at reducing pass overhead. The main part is maintaining post-dominators only during scop detection and not recomputing / verifying everything many many times for no good reason. Somehow this means I ran into a latent bug where ISL split a loop into two, not

Re: Don't query the frontend for unsupported types

On Thu, Sep 21, 2017 at 2:56 PM, Richard Sandiford wrote: > Richard Biener writes: >> On September 20, 2017 2:36:03 PM GMT+02:00, Richard Sandiford >> wrote: >>>When forcing a constant of mode MODE into

Re: [RFC, vectorizer] Allow half_type for left shift in vect_operation_fits_smaller_type?

On Thu, 21 Sep 2017, Jon Beniston wrote: > Hi, > > The GCC vectorizer can't vectorize the following loop even though the target > supports 2-lane SIMD left shift. > > short a[256], b[256]; > foo () > { > int i; > for (i=0; i<256; i++) > { a[i] = b[i] << 4; } >

[GCC][PATCH][TESTSUITE][ARM][COMMITTED] Invert check to misalign in vect_hw_misalign (PR 78421)

Hi All, Commit r244796 changed vect_hw_misalign for arm to check against arm_vect_no_misalign. However vect_hw_misalign is supposed to check if a target supports misalign access, while arm_vect_no_misalign checks that a target only supports aligned access. As such the results need to be inverted

Re: [PATCH] Fix PR82255 (vectorizer cost model overcounts some vector load costs)

On Thu, Sep 21, 2017 at 3:15 PM, Bill Schmidt wrote: > On Sep 21, 2017, at 2:37 AM, Richard Biener wrote >> >> On Wed, Sep 20, 2017 at 9:17 PM, Bill Schmidt >> wrote: >>> On Sep 20, 2017, at 2:14 PM, Bill

Re: [PATCH][2/2] early LTO debug, main part

On Thu, Sep 21, 2017 at 04:29:34PM +0200, Pierre-Marie de Rodat wrote: > On 09/20/2017 08:08 PM, Jeff Law wrote: > > > As for general DWARF5 testing, I think best coverage is GDB (say guality > > > testing with -gdwarf-5), I think GDB 8.0 should have the needed support. > > > I'll try to install

Re: [PATCH][2/2] early LTO debug, main part

On 09/20/2017 08:08 PM, Jeff Law wrote: As for general DWARF5 testing, I think best coverage is GDB (say guality testing with -gdwarf-5), I think GDB 8.0 should have the needed support. I'll try to install it (am only at 7.12.1 right now) and try to do some testing. > What about Pierre-Marie's

[PATCH] Rename existing insn_cost to insn_sched_cost

haifa-sched exports an insn_cost function, but it is only used in a few places and specialised to scheduling. This patch renames it to insn_sched_cost. Okayed by Jeff at https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00202.html, committing it now. Segher 2017-09-21 Segher Boessenkool

RE: [PATCH, i386] Avoid fixed 512-bit vector size in constant set for Intel AVX512 configuration

2017-09-21 Sergey Shalnov gcc/ * config/i386/sse.md(define_insn "mov_internal"): Changed (const_string "XI") to (const_string "") gcc/testsuite/ * gcc.target/i386/avx512f-constant-set.c: New test for fixed vector length usage.

Re: [PATCH] toplev: read from /dev/urandom only when needed

On Thu, 21 Sep 2017, Jakub Jelinek wrote: > Why isn't init_local_tick done at the get_random_seed time too? > I.e. inlined into get_random_seed by hand like you've done for > init_random_seed? init_local_tick initializes the 'local_tick' global variable that is directly accessed from coverage.c.

Re: [PATCH][aarch64] Fix error calls in aarch64 code so they can be tranlated

On 09/20/2017 05:36 PM, Steve Ellcey wrote: On Tue, 2017-09-19 at 10:49 -0600, Martin Sebor wrote: On 09/19/2017 09:54 AM, Steve Ellcey wrote: On Tue, 2017-09-19 at 09:50 +0200, Frédéric Marchal wrote: error (is_pragma ? G_("missing name in %<#pragma target\(\"%s=\")%>")

[OpenACC] Don't restrict ACC wait arguments to constants in fortran

I noticed that gfortran complains when the integer wait queue argument for the acc wait directive is not a constant value. That's an odd restriction, that not even the wait clause enforces. Considering that this patch is one-liner, I've committed this patch to trunk as obvious to remove this

Re: [PATCH, i386] Enable option -mprefer-avx256 added for Intel AVX512 configuration

On Thu, Sep 21, 2017 at 11:25 AM, Shalnov, Sergey wrote: > gcc/ChangeLog: > > 2017-09-21 Sergey Shalnov > > * config/i386/i386.c (flag_opts): Added a macro for new option > (ix86_preferred_simd_mode): Prefer 256-bit AVX modes

Re: [PATCH, i386] Avoid fixed 512-bit vector size in constant set for Intel AVX512 configuration

On Thu, Sep 21, 2017 at 3:41 PM, Shalnov, Sergey wrote: > Hi, > GCC uses full 512-bit register to keep the constant. This constant uses in > the code further but with 128-bit vector length. > The patch avoid fixed large vector length usage. > > For the simple code: >

Re: [PATCH][GRAPHITE] Fix PR71351

On Thu, Sep 21, 2017 at 5:07 AM, Richard Biener wrote: > > This PR is about code generation issues with us inserting "loop header > copies" in the attempt to cover up cases where the loop doesn't run. > But we are disregarding such cases early already. Thus the simple > fix

[PATCH, i386] Avoid fixed 512-bit vector size in constant set for Intel AVX512 configuration

Hi, GCC uses full 512-bit register to keep the constant. This constant uses in the code further but with 128-bit vector length. The patch avoid fixed large vector length usage. For the simple code: void my_test(short *table) { for (int i = 0; i < 128; ++i) { table[i] = -1; } } It

Re: [PATCH] toplev: read from /dev/urandom only when needed

On Wed, Sep 20, 2017 at 11:39:26PM +0300, Alexander Monakov wrote: > --- a/gcc/toplev.c > +++ b/gcc/toplev.c > @@ -239,7 +239,7 @@ announce_function (tree decl) > } > } > > -/* Initialize local_tick with a random number or -1 if > +/* Initialize local_tick with the time of day, or -1 if >

Re: [PATCH][GRAPHITE] Fix IL after codegen errors

On Thu, Sep 21, 2017 at 4:44 AM, Richard Biener wrote: > > The following fixes the IL after code generation errors so we can > continue processing SCOPs. This increases the number of transformed > loop nests in SPEC CPU 2006 by 50%. > > Bootstrap and regtest running on

Re: [PATCH] Fix PR82255 (vectorizer cost model overcounts some vector load costs)

On Sep 21, 2017, at 2:37 AM, Richard Biener wrote: > > On Wed, Sep 20, 2017 at 9:17 PM, Bill Schmidt > wrote: >> On Sep 20, 2017, at 2:14 PM, Bill Schmidt >> wrote: >>> >>> On Sep 20, 2017, at 3:49 AM,

Re: Don't query the frontend for unsupported types

Richard Biener writes: > On September 20, 2017 2:36:03 PM GMT+02:00, Richard Sandiford > wrote: >>When forcing a constant of mode MODE into memory, force_const_mem >>asks the frontend to provide the type associated with that mode. >>In

Re: [PATCH][aarch64] Enable ifunc resolver attribute by default

On Tue, 5 Sep 2017, Steve Ellcey wrote: > 2017-09-05  Steve Ellcey   > > * config.gcc: Add new case statement to set > default_gnu_indirect_function.  Remove it from x86_64-*-linux*, > i[34567]86-*, powerpc*-*-linux*spe*, powerpc*-*-linux*,

[RFC, vectorizer] Allow half_type for left shift in vect_operation_fits_smaller_type?

Hi, The GCC vectorizer can't vectorize the following loop even though the target supports 2-lane SIMD left shift. short a[256], b[256]; foo () { int i; for (i=0; i<256; i++) { a[i] = b[i] << 4; } } The reason seems to be GCC is promoting the source from short

Re: [PATCH] Fix PR82144

On Tue, 12 Sep 2017, Richard Biener wrote: > > The following avoids adding DW_AT_alignment twice by not doing it > for incomplete types. > > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. > > Alex, is that ok or do we want DW_AT_alignment for incomplete types as > well? Alex,

[PATCH] Fix PR82276

The following fixes PR82276 and PR82244 in a slightly different way to ensure VRP is able to fully propagate out asserts on abnormals to restore valid SSA form. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. Richard. 2017-09-21 Richard Biener

Re: [PATCH][AArch64] PR71951: Fix unwinding with -fomit-frame-pointer

James Greenhalgh wrote: > This seems like a bit of a theoretical issue as we would normally build > libgcc with -fno-omit-frame-pointer anyway, but it can't hurt to guarantee > this, so OK. It's not theoretical since there were multiple users reporting unwinding issues, so clearly doing

Re: Backtrace library [3/3]

Hi! On Fri, 14 Sep 2012 14:20:08 -0700, Ian Lance Taylor wrote: >> [libbacktrace] > I won't commit for a day or two in case anybody sees a > problem in the implementation. Eventually got committed, trunk r191397. I just happened to notice that contrib/gcc_update never got

Re: match.pd handling of three-constant bitops

On Thu, Sep 21, 2017 at 1:17 PM, Richard Sandiford wrote: > Richard Biener writes: >> On Wed, Sep 20, 2017 at 2:18 PM, Richard Sandiford >> wrote: >>> natch.pd tries to reassociate two bit operations if both

Re: [PATCH] Improve stack reuse for addressable args/retval of inlined functions (PR sanitizer/81715)

On Thu, 21 Sep 2017, Jakub Jelinek wrote: > Hi! > > As can be seen on this function (trying to show what some Linux kernel > driver does a lot), we don't reuse stack slots for addressable args/retvals > of inlined functions. For variables inside lexical scopes, including inline > functions, we

Re: Enable no-exec stacks for more targets using the Linux kernel

On Wed, Sep 20, 2017 at 12:25:46PM +, Joseph Myers wrote: > On Wed, 20 Sep 2017, Andreas Schwab wrote: > > > On Sep 19 2017, Joseph Myers wrote: > > > > > I've sent a glibc patch > > > . I think > > >

Re: match.pd handling of three-constant bitops

Richard Biener writes: > On Wed, Sep 20, 2017 at 2:18 PM, Richard Sandiford > wrote: >> natch.pd tries to reassociate two bit operations if both of them have >> constant operands. However, with the polynomial integers added later, >>

Re: [PING, ARM] Handle DWARF2_UNWIND_INFO in arm_except_unwind_info

Hello Ramana, > On 20 Sep 2017, at 15:06, Ramana Radhakrishnan > wrote: >> * common/config/arm/arm-common.c (arm_except_unwind_info): >> Handle DWARF2_UNWIND_INFO. >> As I mentioned in the course of another discussion, the dwarf2 unwind support >> could

Re: Enable no-exec stacks for more targets using the Linux kernel

> Thanks. I think this adequately confirms my glibc patch is safe for ia64. > The questions above remain for hppa and microblaze. HP-PA uses function descriptors like IA-64 so same outcome. -- Eric Botcazou

[PATCH] Improve stack reuse for addressable args/retval of inlined functions (PR sanitizer/81715)

Hi! As can be seen on this function (trying to show what some Linux kernel driver does a lot), we don't reuse stack slots for addressable args/retvals of inlined functions. For variables inside lexical scopes, including inline functions, we emit clobber stmts during gimplification, but there are

RE: [PATCH] Fix PR79622

> -Original Message- > From: Richard Biener [mailto:richard.guent...@gmail.com] > Sent: 20 September 2017 17:52 > To: Tamar Christina > Cc: Richard Biener; gcc-patches@gcc.gnu.org; nd > Subject: Re: [PATCH] Fix PR79622 > > On Tue, Sep 19, 2017 at 5:54 PM, Tamar Christina >

Re: configure erroneously detects eh_frame misoptimization

Quoth Andrew Pinski: > Please https://gcc.gnu.org/contribute.html for some more information > on the all of the requirements when it comes to submitting a patch. Thanks for the pointers. Testing the change against the trunk, I find that the problem no longer exists, because printf is used

[PATCH][GRAPHITE] Fix PR71351

This PR is about code generation issues with us inserting "loop header copies" in the attempt to cover up cases where the loop doesn't run. But we are disregarding such cases early already. Thus the simple fix is to not emit those - we have no idea what values to use for reduction results

[PATCH] Fix tests for std::clamp

The tests using std::greater need to reverse the order of the 'hi' and 'lo' arguments, so that the precondition !comp(hi, lo) is met. * testsuite/25_algorithms/clamp/1.cc: Fix order of arguments and expected results when using predicate defining reverse order. *

[PATCH][GRAPHITE] Fix IL after codegen errors

The following fixes the IL after code generation errors so we can continue processing SCOPs. This increases the number of transformed loop nests in SPEC CPU 2006 by 50%. Bootstrap and regtest running on x86_64-unknown-linux-gnu. Richard. 2017-09-21 Richard Biener

RE: [PATCH, i386] Enable option -mprefer-avx256 added for Intel AVX512 configuration

gcc/ChangeLog: 2017-09-21 Sergey Shalnov * config/i386/i386.c (flag_opts): Added a macro for new option (ix86_preferred_simd_mode): Prefer 256-bit AVX modes when the flag -mprefer-avx256 is on (ix86_autovectorize_vector_sizes): Avoid

RE: Enable no-exec stacks for more targets using the Linux kernel

> -Original Message- > From: Joseph Myers [mailto:jos...@codesourcery.com] > Sent: Wednesday, September 20, 2017 5:52 PM > To: Nagaraju Mekala > Cc: sch...@suse.de; gcc-patches@gcc.gnu.org; l...@redhat.com; > d...@anglin.bell.net; wil...@tuliptree.org; Michael Eager >

Re: [committed][PATCH] Stack clash protection patch 04/08 - V4

Jeff Law writes: > This patch introduces the x86 stack clash protected prologue support as > well as the tests. I believe the only change since V3 was the more > aggressive introduction of scheduling barriers. It also enables the > stack-clash tests for x86 targets. > > The

Re: [committed][PATCH] Stack clash protection patch 01/08 - V4

Hi Jeff, > * gcc.dg/stack-check-2.c: New test. > * lib/target-supports.exp > (check_effective_target_supports_stack_clash_protection): New > function. > (check_effective_target_frame_pointer_for_non_leaf): Likewise. >

[PATCH] [testsuite, ARM] Backport to GCC 7 branch

Hi, Can I backport my patch r249639 (Add -mfloat-abi=hard to arm_neon_ok) to the gcc-7 branch ? It fixes a few false failures. It applies cleanly to current trunk, and we have had it in our linaro-7-branch for a while. Thanks. Christophe gcc/ Backport from trunk r249639.

Re: [PATCH] rs6000: Don't touch below the stack pointer (PR77687)

Hi Segher, > On 19 Sep 2017, at 23:21, Segher Boessenkool > wrote: > > With the 32-bit SVR4 ABI we don't have a red zone, so we have to restore > the callee-saved registers before we restore the stack pointer. > > The previous fix for this PR failed in two ways,

Re: [PATCH] toplev: read from /dev/urandom only when needed

On Wed, Sep 20, 2017 at 10:39 PM, Alexander Monakov wrote: > Hi, > > Most compiler invocations don't actually need an entropy source, so > open-read-close syscall sequence on /dev/urandom that GCC performs on > each startup is useless (and can easily be avoided). > > This

Re: [Patch] Edit contrib/ files to download gfortran prerequisites

On Wed, Sep 20, 2017 at 10:35 PM, Damian Rouson wrote: > Attached is a patch that adds the downloading of gfortran prerequisites > OpenCoarrays and MPICH in the contrib/download_prerequisites script. The > patch also provides a useful error message when neither

Re: [PATCH] Fix PR82255 (vectorizer cost model overcounts some vector load costs)

On Wed, Sep 20, 2017 at 9:17 PM, Bill Schmidt wrote: > On Sep 20, 2017, at 2:14 PM, Bill Schmidt wrote: >> >> On Sep 20, 2017, at 3:49 AM, Richard Sandiford >> wrote: >>> >>> But I think this shows up

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

Attached is an updated patch, where I'm adding -fdefault-real-10 according to Steve's suggestion. As with -fdefault-real-8 and -fdefault-real-16, I'm choosing to set the double kind to 16 in this case. Also I'm renaming flag_default_real to flag_default_real_8 (for symmetry reasons and to make the

Re: [PATCH] Improve x86_64 *movqi_internal at -Os (PR target/82260)

On Wed, Sep 20, 2017 at 8:58 PM, Jakub Jelinek wrote: > Hi! > > As mentioned in the PR, in some cases (one or both *movqi_internal > operands %dil/%sil/%bpl/%spl, neither %r*b) the movl variant is smaller > and in cases where movb and movl is the same size, we might as well

Re: [PATCH] [i386, libgcc] PR 82196 -mcall-ms2sysv-xlogues emits wrong AVX/SSE MOV

On Thu, Sep 21, 2017 at 3:58 AM, Daniel Santos wrote: > On 09/19/2017 01:58 AM, Jakub Jelinek wrote: >> What can be done in libgcc is detect in configure whether the assembler >> supports AVX, and if not, provide some alternative (e.g. because the insns >> are always the