[patch, doc] fix some overfull hboxes

I've checked in this patch to fix some formatting problems that caused overfull hbox (that is, lines that overflow the margin) warnings when building the GCC user manual. This isn't exhaustive -- in particular, I see that the long CPU names in the AArch64 and ARM options sections are causing

Re: [PATCH][arm] Add -mverbose-cost-dump and de-verbosify cost dumps

On 12/14/2017 10:50 PM, Sandra Loosemore wrote: On 12/14/2017 11:48 AM, Kyrill Tkachov wrote: [snip] Thanks, done. I haven't created a new Target-specific developers options table but instead listed the targets the options apply to in parentheses. Attached is the latest iteration. Thank

[committed] correct handling of anti-ranges in -Warray-bounds for built-ins (PR 83446)

I checked in the attached patch to restore i686 bootstrap due to a -Warray-bounds false positive triggered by the -Wrestrict enhancement committed yesterday in r255758. Martin PR bootstrap/83446 - Bootstrap failed on i686 gcc/testsuite/ChangeLog: PR bootstrap/83446 *

[v2 of PATCH 06/14] Strip location wrappers in operand_equal_p

On Mon, 2017-12-11 at 18:37 -0500, Jason Merrill wrote: > On 11/10/2017 04:45 PM, David Malcolm wrote: > > gcc/c-family/ChangeLog: > > * c-warn.c (sizeof_pointer_memaccess_warning): Strip any > > location > > wrappers from src and dest. > > Here the existing calls to

[i386] PR81842 [CET] -fcf-protection -mcet is incompatible with makecontext family functions

-fcf-protection -mcet is incompatible with makecontext family functions since they can't properly set up and destroy shadow stack pointer. This change provides a mechanism to help detection shadow stack compatibility. The current proposal is to add -mcheck-shstk-compat option which will predefine

[patch, doc] fix paste-o (?)

Here's another trivial cleanup for an error in the manual I spotted while looking for something else: in the ARC Options section, there was an @opindex and description for -mlra, but no @item table entry. Looks like this was probably a cut-and-paste error. Patch committed as obvious.

[PATCH, testsuite]: Avoid -Wformat warnings in guality.h

The patch avoids following -Wformat warnings for 64bit targets: guality.h: In function ‘guality_check’: guality.h:366:19: warning: format ‘%lli’ expects argument of type ‘long long int’, but argument 4 has type ‘gualchk_t’ {aka ‘long int’} [-Wformat=] fprintf (stderr, "PASS: " GUALITY_TEST ":

Re: [patch,committed] Remove external links that texinfo would shred.

On Tue, 11 Jul 2017, Georg-Johann Lay wrote: > texinfo is shredding external links. > > Applied the following patch to prevent uses from 404 not found. > > Johann > > gcc/ > * doc/extend.texi (AVR Function Attributes): Remove weblink to > Binutils doc as TEXI will mess them up. >

[committed] hppa: Fix comment for pa_som_asm_init_sections

Committed to trunk. Dave -- John David Anglin dave.ang...@bell.net 2017-12-17 John David Anglin * config/pa/pa.c (pa_som_asm_init_sections): Fix comment. Index: config/pa/pa.c === ---

[v2 of PATCH 13/14] c-format.c: handle location wrappers

On Mon, 2017-12-11 at 18:45 -0500, Jason Merrill wrote: > On 11/10/2017 04:45 PM, David Malcolm wrote: > > gcc/c-family/ChangeLog: > >* c-format.c (check_format_arg): Strip any location wrapper > > around > >format_tree. > > --- > >gcc/c-family/c-format.c | 9 - > >1

Re: [PATCH] Support -std=f2018

On 12/17/2017 02:02 AM, Janne Blomqvist wrote: > The Fortran committee has decided to rename the upcoming Fortran 2015 > standard to Fortran 2018. This is not a reflection of a three year > delay in the process, but rather they are following other standards in > adopting the year of publication

Re: [PING 2][PATCH] enhance -Wrestrict to handle string built-ins (PR 78918)

On Sat, Dec 16, 2017 at 4:01 PM, Martin Sebor wrote: > On 12/11/2017 03:27 PM, Jeff Law wrote: >> >> On 12/08/2017 12:19 PM, Martin Sebor wrote: >>> >>> Attached is revision 8 of the patch with the changes suggested >>> and/or requested below. >> >> >> [ Big snip. ] >> >>> >>>

[PATCH v2] libgo: Add support for sh

Hello! This is the second version of my patch to add support for SuperH in libgo. The changes over my first patch in [1] are: * account for little- and big-endian targets * account for sh3- and sh4-specific parameters I have not added support for SH-1 and SH-2 targets for now as most Linux

Re: [PATCH][i386] Correct imul (r64) latency for modern Intel CPUs

On 2017.12.17 at 12:26 +0100, Jan Hubicka wrote: > > Since Nehalem the 64bit multiplication latency is three cycles, not > > four. So update the costs to reflect reality. > > I looked into the imul latencies and was a bit confused, decided to look > into it later and forgot. > > Agner Fog's

Re: [PATCH][i386] Correct imul (r64) latency for modern Intel CPUs

> Since Nehalem the 64bit multiplication latency is three cycles, not > four. So update the costs to reflect reality. I looked into the imul latencies and was a bit confused, decided to look into it later and forgot. Agner Fog's table http://www.agner.org/optimize/instruction_tables.pdf lists

Re: [PATCH] Support -std=f2018

Apologies for lobbing this request to all you wonderful folk who maintain and develop GFORTRAN. Given that you are making noises about Fortran 2018 - and the language is still alive, kicking and thriving - can you recommend and/or point me at a public domain GUI that works well with

[PATCH] Support -std=f2018

The Fortran committee has decided to rename the upcoming Fortran 2015 standard to Fortran 2018. This is not a reflection of a three year delay in the process, but rather they are following other standards in adopting the year of publication for the name. For more details see N2144. This patch

[PATCH][i386] Correct imul (r64) latency for modern Intel CPUs

Since Nehalem the 64bit multiplication latency is three cycles, not four. So update the costs to reflect reality. Tested on X86_64. OK for trunk? Thanks. * x86-tune-costs.h (skylake_cost, core_cost): Decrease r64 multiply latencies. * gcc.target/i386/wmul-3.c: New test.