[Patch, i386] PR 59422 - Support more targets for function multi versioning

PR gcc/59422 This patch extends the supported targets for function multi versiong to also include Haswell, Silvermont, and the most recent AMD models. It also prioritizes AVX2 versions over AMD specific pre-AVX2 versions.

Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning

+1,9 @@ +2013-12-14 Allan Sandfeld Jensen sandf...@kde.org + +PR gcc/59422 +* config/i386/cpuinfo.c: Detect sse4a, fma4, xop and fma +ISAs and recent Intel and AMD models. + 2013-12-12 Zhenqiang Chen zhenqiang.c...@arm.com * config.host (arm*-*-uclinux*): Move t

Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning

Patch updated to keep libgcc enums backwards compatible. `Allan Index: gcc/ChangeLog === --- gcc/ChangeLog (revision 205984) +++ gcc/ChangeLog (working copy) @@ -1,3 +1,9 @@ +2013-12-14 Allan Sandfeld Jensen sandf...@kde.org

Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning

On Monday 16 December 2013, Gopalasubramanian, Ganesh wrote: Btw, I couldn't find anything that corresponds to gcc's btver2 arch. Is that an old term for what has become the Jaguar architecture? Yes, btver2 = jaguar. We have the name as per its family name (i.e, bobcat family) in GCC.

Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning

On Monday 16 December 2013, Uros Bizjak wrote: On Mon, Dec 16, 2013 at 10:34 AM, Uros Bizjak ubiz...@gmail.com wrote: On Sun, Dec 15, 2013 at 7:54 PM, Allan Sandfeld Jensen carew...@gmail.com wrote: Hi again On Wednesday 11 December 2013, Uros Bizjak wrote: Hello! PR gcc

Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning

On Tuesday 17 December 2013, Allan Sandfeld Jensen wrote: On Monday 16 December 2013, Uros Bizjak wrote: On Mon, Dec 16, 2013 at 10:34 AM, Uros Bizjak ubiz...@gmail.com wrote: On Sun, Dec 15, 2013 at 7:54 PM, Allan Sandfeld Jensen carew...@gmail.com wrote: Hi again

Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning

`Allan Index: gcc/ChangeLog === --- gcc/ChangeLog (revision 206065) +++ gcc/ChangeLog (working copy) @@ -1,3 +1,9 @@ +2013-12-14 Allan Sandfeld Jensen sandf...@kde.org + +PR gcc/59422 +* config/i386/i386.c: Extend function

Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning

On Wednesday 18 December 2013, Gopalasubramanian, Ganesh wrote: Ping! Gopalasubramanian, Ganesh ganesh.gopalasubraman...@amd.com wrote: Yes, I figured that was the original idea behind it, but the final family of the jaguar processors seems to have become 16h instead of 14h (bobcat) at

Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning

On Thursday 19 December 2013, Gopalasubramanian, Ganesh wrote: Yes, I changed that in the last patch, though I consider it momentarily problematic because you do not yet enable AVX with march=btver2 (AVX versions would currently be better than btver2 versions for a btver2 arch), but expect

Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning

On Thursday 19 December 2013, Gopalasubramanian, Ganesh wrote: Sorry, I must have been looking at an older version, but as I said I already did enable it in the latest patch. (see http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01577.html ) Sorry for causing another revision but we would

Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning

On Monday 23 December 2013, H.J. Lu wrote: On Thu, Dec 19, 2013 at 11:20:39AM +0100, Allan Sandfeld Jensen wrote: On Thursday 19 December 2013, Gopalasubramanian, Ganesh wrote: Sorry, I must have been looking at an older version, but as I said I already did enable it in the latest patch

Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning

On Monday 23 December 2013, Allan Sandfeld Jensen wrote: On Monday 23 December 2013, H.J. Lu wrote: On Thu, Dec 19, 2013 at 11:20:39AM +0100, Allan Sandfeld Jensen wrote: On Thursday 19 December 2013, Gopalasubramanian, Ganesh wrote: Sorry, I must have been looking at an older version

Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning

On Monday 23 December 2013, H.J. Lu wrote: On Mon, Dec 23, 2013 at 8:57 AM, Allan Sandfeld Jensen carew...@gmail.com wrote: On Monday 23 December 2013, Allan Sandfeld Jensen wrote: On Monday 23 December 2013, H.J. Lu wrote: On Thu, Dec 19, 2013 at 11:20:39AM +0100, Allan Sandfeld Jensen

Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning

On Monday 23 December 2013, H.J. Lu wrote: If you use {corei7-avx, M_INTEL_COREI7_SANYBRIDGE}, {core-avx2, M_INTEL_COREI7_HASWELL}, will it cause any problems? When there are both Actually I seems I don't need these definitions any more after your clean-up of Intel architecture

Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning

On Tuesday 24 December 2013, H.J. Lu wrote: Will libgcc/config/i386/cpuinfo.c update be a separate patch? Should we use a single definition for both i386.c and libgcc? Currently they need to be in the same patch. But yes, moving the definition out to a common header would probably be a good

Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning

On Wednesday 25 December 2013, Uros Bizjak wrote: On Tue, Dec 24, 2013 at 4:17 PM, Allan Sandfeld Jensen carew...@gmail.com wrote: Will libgcc/config/i386/cpuinfo.c update be a separate patch? Should we use a single definition for both i386.c and libgcc? Currently they need

Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning

On Thursday 26 December 2013, Gopalasubramanian, Ganesh wrote: Hi, (get_amd_cpu): Handle AMD_BOBCAT, AMD_JAGUAR, AMDFAM15H_BDVER2 and AMDFAM15H_BDVER3. As mentioned earlier, we would like to stick with BTVER1 and BTVER2 instead of using BOBCAT or JAGUAR. Attached patch does the

[Patch, i386] Separate Intel processor with expanded ISA

they support. Regards `Allan Index: gcc/ChangeLog === --- gcc/ChangeLog (revision 206233) +++ gcc/ChangeLog (working copy) @@ -1,3 +1,9 @@ +2013-12-29 Allan Sandfeld Jensen sandf...@kde.org + + * config/i386/i386.c

Re: [Patch, i386] Separate Intel processor with expanded ISA

No comments? On Sunday 29 December 2013, Allan Sandfeld Jensen wrote: The function dispatcher might currently choose functions declared with target(arch=ivybridge) on a Sandy Bridge CPU. This happens because the function is only detected as sandybridge when generated. The attached patch

Re: [Patch, i386] Separate Intel processor with expanded ISA

Updated patch with test. diff --git a/gcc/ChangeLog b/gcc/ChangeLog index ccbea0f..e80c30b 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,8 @@ +2013-12-29 Allan Sandfeld Jensen sandf...@kde.org + * config/i386/i386.c (get_builtin_code_for_version): Separate + Westmere from Nehalem

[Patch, i386] Support AES, F16C, BMI and BMI2 targets in multiversioning

I recently wanted to use multiversioning for BMI2 specific extensions PDEP/PEXT, and noticed it wasn't there. So I wrote this patch to add it, and also added AES, F16C and BMI1 for completeness. Happy new year `Allan commit 062c09d45d22302ffbd4f86d88e16a1a0d49cd80 Author: Allan Sandfeld Jensen

Re: [Patch, i386] Support AES, F16C, BMI and BMI2 targets in multiversioning

On Wednesday 31 December 2014, Jakub Jelinek wrote: On Wed, Dec 31, 2014 at 01:28:47PM +0100, Allan Sandfeld Jensen wrote: I recently wanted to use multiversioning for BMI2 specific extensions PDEP/PEXT, and noticed it wasn't there. So I wrote this patch to add it, and also added AES, F16C

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

On Monday 26 January 2015, H.J. Lu wrote: On Mon, Jan 26, 2015 at 11:08 AM, Allan Sandfeld Jensen carew...@gmail.com wrote: On Monday 26 January 2015, H.J. Lu wrote: On Mon, Jan 26, 2015 at 10:53 AM, Allan Sandfeld Jensen carew...@gmail.com wrote: Committed with a bunch of fixes

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

On Monday 26 January 2015, you wrote: On Mon, Jan 26, 2015 at 10:38 AM, Allan Sandfeld Jensen al...@carewolf.com wrote: On Monday 26 January 2015, H.J. Lu wrote: On Sun, Jan 25, 2015 at 10:37 AM, Uros Bizjak ubiz...@gmail.com wrote: On Sun, Jan 25, 2015 at 7:23 PM, Uros Bizjak ubiz

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

On Monday 26 January 2015, H.J. Lu wrote: On Mon, Jan 26, 2015 at 10:53 AM, Allan Sandfeld Jensen carew...@gmail.com wrote: Committed with a bunch of fixes (e.g. missing fold_builtin_cpu part in gcc/config/i386/i386.c, and mv17.C test didn't compile at all due to missing

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

On Monday 26 January 2015, H.J. Lu wrote: On Sun, Jan 25, 2015 at 10:37 AM, Uros Bizjak ubiz...@gmail.com wrote: On Sun, Jan 25, 2015 at 7:23 PM, Uros Bizjak ubiz...@gmail.com wrote: On Sat, Jan 24, 2015 at 11:49 AM, Allan Sandfeld Jensen al...@carewolf.com wrote: On Saturday 24

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

On Saturday 24 January 2015, Uros Bizjak wrote: On Mon, Jan 12, 2015 at 6:02 PM, Uros Bizjak ubiz...@gmail.com wrote: Hello! On Wed, Dec 31, 2014 at 01:28:47PM +0100, Allan Sandfeld Jensen wrote: I recently wanted to use multiversioning for BMI2 specific extensions PDEP/PEXT

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

On Wednesday 31 December 2014, Jakub Jelinek wrote: On Wed, Dec 31, 2014 at 01:28:47PM +0100, Allan Sandfeld Jensen wrote: I recently wanted to use multiversioning for BMI2 specific extensions PDEP/PEXT, and noticed it wasn't there. So I wrote this patch to add it, and also added AES, F16C

Re: [Patch][i386] PR 70118: Fix ubsan warning on SSE2 loadl_epi64 and storel_epi64

On Sunday 27 November 2016, Marc Glisse wrote: > On Sat, 26 Nov 2016, Allan Sandfeld Jensen wrote: > > Use the recently introduced unaligned variant of __m128i and add a > > similar __m64 and use those to make it clear these two intrinsics > > require neither 128- bit

[Patch][i386] PR 70118: Fix ubsan warning on SSE2 loadl_epi64 and storel_epi64

Use the recently introduced unaligned variant of __m128i and add a similar __m64 and use those to make it clear these two intrinsics require neither 128- bit nor 64-bit alignment. `Allan Index: gcc/config/i386/emmintrin.h === ---

Re: [PATCH] libiberty: Fix -Wimplicit-fallthrough warnings.

On Wednesday 02 November 2016, Mark Wielaard wrote: > -case 11: c+=((hashval_t)k[10]<<24); > -case 10: c+=((hashval_t)k[9]<<16); > -case 9 : c+=((hashval_t)k[8]<<8); > +case 11: c+=((hashval_t)k[10]<<24); /* fall through */ > +case 10: c+=((hashval_t)k[9]<<16); /*

Re: [PATCH] Introduce -Wimplicit-fallthrough={0,1,2,3,4,5}

On Tuesday 11 October 2016, Jakub Jelinek wrote: > Hi! > > The following patch introduces difference warning levels for > -Wimplicit-fallthrough warning, so projects can choose if they want to > honor only attributes (-Wimplicit-fallthrough=5), or what kind of comments. > =4 is very picky and

Re: [Patch][i386] PR 70118: Fix ubsan warning on SSE2 loadl_epi64 and storel_epi64

On Tuesday 06 December 2016, Uros Bizjak wrote: > Hello! > > > 2016-11-30 Allan Sandfeld Jensen <allan.jen...@qt.io> > > > >PR target/70118 > >* gcc/config/i386/mmintrin.h (__m64_u): New type > >* gcc/config/i386/emmi

Re: [Patch][i386] PR 70118: Fix ubsan warning on SSE2 loadl_epi64 and storel_epi64

Trying again, this time with changelog. gcc/ 2016-11-30 Allan Sandfeld Jensen <allan.jen...@qt.io> PR target/70118 * gcc/config/i386/mmintrin.h (__m64_u): New type * gcc/config/i386/emmintrin.h (_mm_loadl_epi64, _mm_storel_epi64): Make the allowed una

Re: [PATCH] [x86] Avoid builtins for SSE/AVX2 immidiate logical shifts

On Saturday 22 April 2017, Allan Sandfeld Jensen wrote: > Replaces definitions of immediate logical shift intrinsics with GCC > extension syntax. Tests are added to ensure the intrinsics still produce > the right instructions and that a few basic optimizations now work. >

Re: [PATCH] [x86] Avoid builtins for SSE/AVX2 immidiate logical shifts

On Monday 24 April 2017, Jakub Jelinek wrote: > On Mon, Apr 24, 2017 at 09:33:09AM +0200, Allan Sandfeld Jensen wrote: > > --- a/gcc/config/i386/avx2intrin.h > > +++ b/gcc/config/i386/avx2intrin.h > > @@ -667,7 +667,7 @@ extern __inline __m256i > > > >

Re: [PATCH] [x86] Avoid builtins for SSE/AVX2 immidiate logical shifts

On Monday 24 April 2017, Jakub Jelinek wrote: > On Mon, Apr 24, 2017 at 09:51:29AM +0200, Allan Sandfeld Jensen wrote: > > On Monday 24 April 2017, Jakub Jelinek wrote: > > > On Mon, Apr 24, 2017 at 09:33:09AM +0200, Allan Sandfeld Jensen wrote: > > > > ---

Re: [PATCH] [x86] Avoid builtins for SSE/AVX2 immidiate logical shifts

On Monday 24 April 2017, Allan Sandfeld Jensen wrote: > On Monday 24 April 2017, Jakub Jelinek wrote: > > On Mon, Apr 24, 2017 at 10:02:40AM +0200, Allan Sandfeld Jensen wrote: > > > > That said, both the options I've mentioned above provide the same > > &g

Re: [PATCH] [x86] Avoid builtins for SSE/AVX2 immidiate logical shifts

On Monday 24 April 2017, Jakub Jelinek wrote: > On Mon, Apr 24, 2017 at 10:34:58AM +0200, Allan Sandfeld Jensen wrote: > > That is a different instruction. That is the vpsllw not vpsllwi > > > > The intrinsics I changed is the immediate version, I didn't change the >

Re: [PATCH] [x86] Avoid builtins for SSE/AVX2 immidiate logical shifts

On Monday 24 April 2017, Jakub Jelinek wrote: > On Mon, Apr 24, 2017 at 11:01:29AM +0200, Allan Sandfeld Jensen wrote: > > On Monday 24 April 2017, Jakub Jelinek wrote: > > > On Mon, Apr 24, 2017 at 10:34:58AM +0200, Allan Sandfeld Jensen wrote: > > > > T

Re: [PATCH] [x86] Avoid builtins for SSE/AVX2 immidiate logical shifts

On Monday 24 April 2017, Jakub Jelinek wrote: > On Mon, Apr 24, 2017 at 10:02:40AM +0200, Allan Sandfeld Jensen wrote: > > > That said, both the options I've mentioned above provide the same > > > advantages and don't have the disadvantages of pessimizing normal code. >

Re: [PATCH] [x86] Avoid builtins for SSE/AVX2 immidiate logical shifts

On Monday 24 April 2017, Jakub Jelinek wrote: > On Mon, Apr 24, 2017 at 09:33:09AM +0200, Allan Sandfeld Jensen wrote: > > --- a/gcc/config/i386/avx2intrin.h > > +++ b/gcc/config/i386/avx2intrin.h > > @@ -667,7 +667,7 @@ extern __inline __m256i > > > >

Re: [PATCH] [x86] Avoid builtins for SSE/AVX2 immidiate logical shifts

On Tuesday 02 May 2017, Jakub Jelinek wrote: > On Mon, Apr 24, 2017 at 03:15:11PM +0200, Allan Sandfeld Jensen wrote: > > Okay, I have tried that, and I also made it more obvious how the > > intrinsics can become non-immediate shift. > > > > > > diff --gi

Re: [Patch] Use two source permute for vector initialization (PR 85692)

On Mittwoch, 9. Mai 2018 11:08:02 CEST Jakub Jelinek wrote: > On Tue, May 08, 2018 at 01:25:35PM +0200, Allan Sandfeld Jensen wrote: > > 2018-05-08 Allan Sandfeld Jensen <allan.jen...@qt.io> > > 2 spaces between date and name and two spaces between name and email >

Re: [PATCH] Use two source permute for vector initialization (PR 85692, take 2)

On Donnerstag, 10. Mai 2018 09:57:22 CEST Jakub Jelinek wrote: > On Wed, May 09, 2018 at 04:53:19PM +0200, Allan Sandfeld Jensen wrote: > > > > @@ -2022,8 +2022,9 @@ simplify_vector_constructor > > > > (gimple_stmt_iterator > > > > *gsi)> >

[Patch] Use two source permute for vector initialization (PR 85692)

I have tried to fix PR85692 that I opened. 2018-05-08 Allan Sandfeld Jense PR tree-optimization/85692 * tree-ssa-forwprop.c (simplify_vector_constructor): Detect two source permute operations as well. diff --git a/gcc/tree-ssa-forwprop.c

Re: [Patch] Use two source permute for vector initialization (PR 85692)

On Dienstag, 8. Mai 2018 12:42:33 CEST Richard Biener wrote: > On Tue, May 8, 2018 at 12:37 PM, Allan Sandfeld Jensen > > <li...@carewolf.com> wrote: > > I have tried to fix PR85692 that I opened. > > Please add a testcase as well. It also helps if you shortly

[Patch] Request for comments: short int builtins

A little over a year back we had a regression in a point release of gcc because the builtin __builtin_clzs got removed from i386, in part because it is was wrongly named for a target specific builtin, but we were using it in Qt since it existed in multiple compilers. I got the patch removing it

Re: [Patch] Request for comments: short int builtins

On Sonntag, 20. Mai 2018 15:07:59 CEST Richard Biener wrote: > On May 20, 2018 11:01:54 AM GMT+02:00, Allan Sandfeld Jensen <li...@carewolf.com> wrote: > >A little over a year back we had a regression in a point release of gcc > > > >because the builtin __builtin

[Patch][GCC] Document and fix -r (partial linking)

The option has existed and been working for years, make sure it implies the right extra options, and list it in the documentation. 2018-08-01 Allan Sandfeld Jensen gcc/doc * invoke.texi: Document -r gcc/ * gcc.c: Correct default specs for -r --- gcc/doc/invoke.texi | 7 ++- gcc

[PATCH][x86] Match movss and movsd "blend" instructions

Adds the ability to match movss and movsd as blend patterns, implemented in a new method to be able to match these before shuffles, while keeping other blends after. 2018-07-29 Allan Sandfeld Jensen gcc/config/i386 * i386.cc (expand_vec_perm_movs): New method matching movs patterns

Re: [PATCH][x86] Match movss and movsd "blend" instructions

On Donnerstag, 2. August 2018 23:46:37 CEST Jakub Jelinek wrote: > On Thu, Aug 02, 2018 at 10:50:58PM +0200, Allan Sandfeld Jensen wrote: > > Here is the version with __builtin_shuffle. It might be more expectable > > -O0, but it is also uglier. > > I don't find anythi

Re: [PATCH][x86] Match movss and movsd "blend" instructions

On Donnerstag, 2. August 2018 23:15:28 CEST Marc Glisse wrote: > On Thu, 2 Aug 2018, Allan Sandfeld Jensen wrote: > > I forgot. One of the things that makes using __builtin_shuffle ugly is > > that > > __v4si as the suffle argument needs to be in _mm_move_ss, is declar

Re: [PATCH][x86] Match movss and movsd "blend" instructions

On Mittwoch, 1. August 2018 18:51:41 CEST Marc Glisse wrote: > On Wed, 1 Aug 2018, Allan Sandfeld Jensen wrote: > > extern __inline __m128d __attribute__((__gnu_inline__, __always_inline__, > > > > __artificial__)) > > > > _mm_move_sd (__m128d __A, __m12

Re: [PATCH][x86] Match movss and movsd "blend" instructions

On Donnerstag, 2. August 2018 11:18:41 CEST Richard Biener wrote: > On Thu, Aug 2, 2018 at 11:12 AM Allan Sandfeld Jensen > > wrote: > > On Mittwoch, 1. August 2018 18:51:41 CEST Marc Glisse wrote: > > > On Wed, 1 Aug 2018, Allan Sandfeld Jensen wrote: > >

Re: [Patch][GCC] Document and fix -r (partial linking)

On Mittwoch, 1. August 2018 18:32:30 CEST Joseph Myers wrote: > On Wed, 1 Aug 2018, Allan Sandfeld Jensen wrote: > > gcc/ > > > > * gcc.c: Correct default specs for -r > > I don't follow why your changes (which would need describing for each > individual

Re: [Patch][GCC] Document and fix -r (partial linking)

On Mittwoch, 1. August 2018 18:32:30 CEST Joseph Myers wrote: > On Wed, 1 Aug 2018, Allan Sandfeld Jensen wrote: > > gcc/ > > > > * gcc.c: Correct default specs for -r > > I don't follow why your changes (which would need describing for each > individual

Re: [PATCH][x86] Match movss and movsd "blend" instructions

On Mittwoch, 1. August 2018 18:51:41 CEST Marc Glisse wrote: > On Wed, 1 Aug 2018, Allan Sandfeld Jensen wrote: > > extern __inline __m128d __attribute__((__gnu_inline__, __always_inline__, > > > > __artificial__)) > > > > _mm_move_sd (__m128d __A, __m12

Re: [PATCH][x86] Match movss and movsd "blend" instructions

Updated: Match movss and movsd "blend" instructions Adds the ability to match movss and movsd as blend patterns, implemented in a new method to be able to match these before shuffles, while keeping other blends after. 2018-08-11 Allan Sandfeld Jensen gcc/config/i386

Re: [PATCH][x86] Match movss and movsd "blend" instructions

On Samstag, 11. August 2018 11:18:39 CEST Jakub Jelinek wrote: > On Sat, Aug 11, 2018 at 10:59:26AM +0200, Allan Sandfeld Jensen wrote: > > +/* A subroutine of ix86_expand_vec_perm_builtin_1. Try to implement D > > + using movss or movsd. */ > > +static bool > > +e

Re: [Patch][GCC] Document and fix -r (partial linking)

On Freitag, 3. August 2018 13:56:12 CEST Allan Sandfeld Jensen wrote: > On Mittwoch, 1. August 2018 18:32:30 CEST Joseph Myers wrote: > > On Wed, 1 Aug 2018, Allan Sandfeld Jensen wrote: > > > gcc/ > > > > > > * gcc.c: Correct default specs for -r >

Re: [Patch][GCC] Document and fix -r (partial linking)

On Dienstag, 21. August 2018 00:38:58 CEST Joseph Myers wrote: > On Fri, 3 Aug 2018, Allan Sandfeld Jensen wrote: > > > I think you're changing the wrong place for this. If you want -r to be > > > usable with GCC without using -nostdlib (which is an interesting > > >

Re: [Patch][GCC] Document and fix -r (partial linking)

tstrapped, I didn't notice any relevant failures when running the test suite (though I could have missed something, I am never comfortable reading that output). 'Allan >From 07ed41a9afd107c5d45feb1ead7a74ca735a1bb2 Mon Sep 17 00:00:00 2001 From: Allan Sandfeld Jensen Date: Sun, 26 Aug 2018 2

Re: [Patch][GCC] Document and fix -r (partial linking)

On Montag, 27. August 2018 15:37:15 CEST Joseph Myers wrote: > On Sun, 26 Aug 2018, Allan Sandfeld Jensen wrote: > > Patch updated. I specifically edited a number of the existing tests that > > used both -r and -nostdlib and removed -nostdlib so the patch is > > exerci

Re: [Patch][GCC] Document and fix -r (partial linking)

On Montag, 27. August 2018 15:37:15 CEST Joseph Myers wrote: > On Sun, 26 Aug 2018, Allan Sandfeld Jensen wrote: > > Patch updated. I specifically edited a number of the existing tests that > > used both -r and -nostdlib and removed -nostdlib so the patch is > > exerci

[Patch] Make x86-64 a generic architecture as documented

/gcc/ChangeLog @@ -1,3 +1,8 @@ +2019-07-13 Allan Sandfeld Jensen + + * gcc/common/config/i386/i386-common.c (processor_alias_table): Change + x86-64 architecture to use generic tuning and scheduling instead of K8. + 2019-07-11 Jakub Jelinek PR target/91124 diff --git a/gcc

Re: [PATCH] Come up with -flto=auto option.

On Dienstag, 23. Juli 2019 10:30:07 CEST Martin Liška wrote: > Hi. > > As we as openSUSE started using -flto, I see it very handy to have > an option value that will automatically detect number of cores > that can be used for parallel LTRANS phase. > > Thoughts? > That's really nice. How much

Re: [PATCH] Come up with -flto=auto option.

On Mittwoch, 24. Juli 2019 08:45:21 CEST Martin Liška wrote: > On 7/24/19 12:11 AM, Allan Sandfeld Jensen wrote: > > On Dienstag, 23. Juli 2019 10:30:07 CEST Martin Liška wrote: > >> Hi. > >> > >> As we as openSUSE started using -flto, I see it ver

Re: issue with behavior change of gcc -r between gcc-8 and gcc-9

On Wednesday, 1 April 2020 19:48:11 CEST Olivier Hainque wrote: > > -r 's business was to arrange for the linker not to > complain because the closure is incomplete, leaving us > with complete control of the closure. > > It doesn't seem to me there was a really strong motivation > to suddenly