RE: [PATCH][GCC][mingw-w64][Ada] Fix Ada native bootstrap (PR81878).

Hi Eric, > -Original Message- > From: Eric Botcazou > Sent: Friday, October 26, 2018 11:20 > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; char...@adacore.com; > dero...@adacore.com > Subject: Re: [PATCH][GCC][mingw-w64][Ada] Fix Ada native bootstrap > (PR81878). > > > Due to

Re: Turn complete to incomplete types in free_lang_data

On Fri, 26 Oct 2018, Jan Hubicka wrote: > > > OK if it survives more testing on firefox and lto bootstrap? > > > > It looks like a hack to do free_lang_data_in_type from > > free_lang_data_in_decl > > walk - I remember you wanted to unify find_* and free_*? If not doing that > > I did try it :

[PATCH][DOCS][OBVIOUS] Fix typo in documentation of __builtin_expect_with_probability.

Hi. I'm going to install one obvious documentation fix as reported here: https://gcc.gnu.org/ml/gcc/2018-10/msg00252.html Martin gcc/ChangeLog: 2018-10-30 Martin Liska * doc/extend.texi: Fix typo in documentation of __builtin_expect_with_probability. --- gcc/doc/extend.texi

Re: [PATCH][DOCS][OBVIOUS] Fix typo in documentation of __builtin_expect_with_probability.

On Tue, 30 Oct 2018, Martin Liška wrote: > Hi. > > I'm going to install one obvious documentation fix as reported here: > https://gcc.gnu.org/ml/gcc/2018-10/msg00252.html > > Martin > > gcc/ChangeLog: > > 2018-10-30 Martin Liska > > * doc/extend.texi: Fix typo in documentation >

[PATCH] x86: Update VFIXUPIMM* Intrinsics to align with the latest Intel SDM

Hi, The attached patch updates VFIXUPIMM* Intrinsics to align with the latest Intel® 64 and IA-32 Architectures Software Developer’s Manual (SDM). Tested with GCC regression test on x86, no regression. Is it ok? Thanks Wei gcc/ 2018-10-30 Wei Xiao *config/i386/avx512fintrin.h:

[PATCH] Fix PR87800

The following fixes the 416.gamess build with LTO by disregarding vect_internal_def PHIs during SLP build. Bootstrap and regtest running on x86_64-unknown-linux-gnu. Richard. 2018-10-30 Richard Biener PR tree-optimization/87800 * tree-vect-slp.c (vect_build_slp_tree_2): Rej

Re: Turn complete to incomplete types in free_lang_data

> > ... unmerged TYPE_NAMEs which happens only on WPA state. It is leftover of > > my merging during streaming experiment. > > > > I will clean this up and send updated patch. I was bit in hurry leaving > > today > > and wanted to send at least initial patch for discussion. > > OK, btw I notice

Re: [PATCH 6/6] [ARC] Handle store cacheline hazard.

* Claudiu Zissulescu [2018-10-10 11:00:16 +0300]: > Handle store cacheline hazard for A700 cpus by inserting two NOP_S > between ST ST LD or their logical equivalent (like ST ST NOP_S NOP_S > J_L.D LD) > > gcc/ > 2016-08-01 Claudiu Zissulescu > > * config/arc/arc-arch.h (ARC_TUNE_ARC7X

hash-table violation in cselib.c

> 1) cselib_lookup_1: > > $ cat ice.c > a() { b(); } > > $ /dev/shm/objdir/gcc/xgcc -B/dev/shm/objdir/gcc/ ice.c -g -c -fchecking=3 -O > hash table checking failed: equal operator returns true for a pair of values > with a different hash valueduring RTL pass: vartrack > ice.c:1:1: internal compi

Re: [PATCH][RFC] Sanitize equals and hash functions in hash-tables.

On Mon, Oct 29, 2018 at 04:14:21PM +0100, Martin Liška wrote: > +hashtab_chk_error () > +{ > + fprintf (stderr, "hash table checking failed: " > +"equal operator returns true for a pair " > +"of values with a different hash value"); BTW, either use internal_error here, or at least

hash-table violation in gcc/fortran/trans-decl.c

On 10/29/18 12:04 PM, Martin Liška wrote: > 2) gfc_find_module > > $ ./xgcc -B. > /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/coarray/alloc_comp_2.f90 > -fcoarray=single -fchecking=3 > hash table checking failed: equal operator returns true for a pair of values > with a different has

Re: [Patch, regrename] Fix PR87330 : ICE in scan_rtx_reg, at regrename.c

On Tue, 9 Oct 2018 at 04:08, Eric Botcazou wrote: > > > Other notes need not be changed, as they don't hold renamed register > > information. > > > > Ok for trunk? > > No, REG_DEAD & REG_UNUSED note must be recomputed by passes consuming them. > > > 2018-10-09 Sameera Deshpande > > > * gcc/regren

Re: Add a loop versioning pass

(sorry for breaking threading -- I composed a review mail offline but gmail has no way of nicely sending that neither has it a way to bounce messages...) > This patch adds a pass that versions loops with variable index strides > for the case in which the stride is 1. E.g.: > > for (int i =

Re: [AArch64] Add Saphira pipeline description.

On Fri, 26 Oct 2018 at 13:33, Sameera Deshpande wrote: > > Hi! > > Please find attached the patch to add a pipeline description for the > Qualcomm Saphira core. It is tested with a bootstrap and make check, > with no regressions. > > Ok for trunk? > > gcc/ > Changelog: > > 2018-10-26 Sameera Desh

hash-table violation in gcc/cp/pt.c

On 10/29/18 12:04 PM, Martin Liška wrote: > 3) lookup_template_class_1 > > $ ./xg++ -B. > /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/template/ttp23.C -c > -fchecking=3 > hash table checking failed: equal operator returns true for a pair of values > with a different hash > value/home/mar

Re: hash-table violation in gcc/cp/pt.c

On 10/30/18 11:25 AM, Martin Liška wrote: > On 10/29/18 12:04 PM, Martin Liška wrote: >> 3) lookup_template_class_1 >> >> $ ./xg++ -B. >> /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/template/ttp23.C -c >> -fchecking=3 >> hash table checking failed: equal operator returns true for a pair of

Re: [Patch, regrename] Fix PR87330 : ICE in scan_rtx_reg, at regrename.c

On 30/10/2018 10:09, Sameera Deshpande wrote: > On Tue, 9 Oct 2018 at 04:08, Eric Botcazou wrote: >> >>> Other notes need not be changed, as they don't hold renamed register >>> information. >>> >>> Ok for trunk? >> >> No, REG_DEAD & REG_UNUSED note must be recomputed by passes consuming them. >>

[patch] Don't allow the pool allocator to be configured to allocate zero-sized objects

PR bootstrap/87747 would have been significantly easier to track down if the pool allocator had faulted an attempt to configure it to allocate zero-sized objects. Instead, this slipped through and we later hit memory corruption when the assumed size turned out to be different to the configured siz

Re: [PATCH, GCC/ARM, ping3] Fix PR87374: ICE with -mslow-flash-data and -mword-relocations

Ping? Best regards, Thomas On Tue, 23 Oct 2018 at 10:10, Thomas Preudhomme wrote: > > Ping? > > Best regards, > > Thomas > > On Mon, 15 Oct 2018 at 16:01, Thomas Preudhomme > wrote: > > > > Ping? > > > > Best regards, > > > > Thomas > > On Fri, 5 Oct 2018 at 17:50, Thomas Preudhomme > > wrote

Re: [Patch, regrename] Fix PR87330 : ICE in scan_rtx_reg, at regrename.c

On Tue, 30 Oct 2018 at 16:16, Richard Earnshaw (lists) wrote: > > On 30/10/2018 10:09, Sameera Deshpande wrote: > > On Tue, 9 Oct 2018 at 04:08, Eric Botcazou wrote: > >> > >>> Other notes need not be changed, as they don't hold renamed register > >>> information. > >>> > >>> Ok for trunk? > >> >

Fix D compilation on Solaris

I just tried building D on Solaris 11/SPARC and x86 and ran into a couple of issues. The following patch is at least enough to have the build finish on Solaris 11/x86, but on SPARC d21 runs into several BUS errors (probably due to alignment issues). One comment up front: I believe it would be goo

Re: [patch] Don't allow the pool allocator to be configured to allocate zero-sized objects

On Tue, Oct 30, 2018 at 11:55 AM Richard Earnshaw (lists) wrote: > > PR bootstrap/87747 would have been significantly easier to track down if > the pool allocator had faulted an attempt to configure it to allocate > zero-sized objects. Instead, this slipped through and we later hit > memory corru

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

On Mon, Oct 29, 2018 at 04:42:43PM +, Richard Henderson wrote: > On 10/29/18 4:34 PM, Segher Boessenkool wrote: > > Is there some better documentation available? This is what google found > > for me. I would have like better docs (more compact, etc.) Links to > > such would be great to have

Re: [PATCH v4] Avoid unnecessarily numbering cloned symbols.

On 10/29/18 6:43 PM, Michael Ploujnikov wrote: > Thanks for installing the patch while I figure out the SVN access. > - Michael Installed as r265621. Martin

Re: [PATCH] S/390: Allow LARL of literal pool entries

> Am 29.10.2018 um 19:45 schrieb Ulrich Weigand : > > Ilya Leoshkevich wrote: > >> >> UNSPEC_LTREF and friends are necessary in order to communicate the >> dependency on the base register to pass_sched2. When LARL is used, no >> base register is necessary, so in such cases the rewrite must b

[PATCH] Fix __builtin_expect_with_probability documentation

* doc/extend.texi: Fix prototype and description of __builtin_expect_with_probability. Committed to trunk, as discussed on the gcc list. commit 9fb8a9f94f673e7dd12b3a625829db6caaeab99e Author: Jonathan Wakely Date: Tue Oct 30 12:15:14 2018 + Fix __builtin_expect_with_

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

On Sun, Oct 28, 2018 at 01:56:29AM +, Richard Henderson wrote: > On 10/27/18 5:37 AM, Stafford Horne wrote: > > +(define_insn "zero_extendhisi2" > > + [(set (match_operand:SI 0 "register_operand""=r,r") > > + (zero_extend:SI (match_operand:HI 1 "nonimmediate_operand" "r,m

Re: [PATCH][RFC] Sanitize equals and hash functions in hash-tables.

On 10/30/18 11:03 AM, Jakub Jelinek wrote: > On Mon, Oct 29, 2018 at 04:14:21PM +0100, Martin Liška wrote: >> +hashtab_chk_error () >> +{ >> + fprintf (stderr, "hash table checking failed: " >> + "equal operator returns true for a pair " >> + "of values with a different hash value"); >

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

Hello, On Sun, Oct 28, 2018 at 05:54:47PM -0500, Segher Boessenkool wrote: > Hi! > > On Mon, Oct 29, 2018 at 06:47:23AM +0900, Stafford Horne wrote: > > On Sat, Oct 27, 2018 at 09:57:30PM -0500, Segher Boessenkool wrote: > > > > +/* Helper for defining INITIAL_ELIMINATION_OFFSET. > > > > + We a

Ping: [PATCH, testsuite]: check for weak support

Ping. Ok to commit? paul > On Oct 25, 2018, at 2:57 PM, Paul Koning wrote: > > I ran into a failures due to no weak symbol support in my target. This patch > cures that. Is it right? The test case uses "weakref" so I' not 100% sure > that checking for "weak" support is correct. I

Re: Fix D compilation on Solaris

Rainer Orth writes: > * On sparc, I didn't get that far, unfortunately: as I mentioned, many > compilations die with SIGBUS: > > libtool: compile: /var/gcc/regression/trunk/11.5-gcc/build/./gcc/gdc > -B/var/gcc/regression/trunk/11.5-gcc/build/./gcc/ > -B/vol/gcc/sparc-sun-solaris2.11/bin/ -B

[PATCH] Fix PRs70359/86270

This picks up work from earlier this year where Aldy worked on undoing forwprop during out-of-SSA to improve coalescing across backedges. The following patch first rectifies the existing code which is meant to insert necessary copies in places where it then allows coalescing and thus avoids spli

[PATCH] Simplify replace_trapping_overflow

Bootstrap & regtest running on x86_64-unknown-linux-gnu. Richard. 2018-10-30 Richard Biener * tree-eh.c (replace_trapping_overflow): Simplify ABS_EXPR case using ABSU_EXPR. diff --git a/gcc/tree-eh.c b/gcc/tree-eh.c index 1c7d9dc1d59..046405b8a15 100644 --- a/gcc/tree-eh.c

Re: Ping: [PATCH, testsuite]: check for weak support

On 10/30/18 6:55 AM, Paul Koning wrote: > Ping. Ok to commit? > > paul > >> On Oct 25, 2018, at 2:57 PM, Paul Koning wrote: >> >> I ran into a failures due to no weak symbol support in my target. This >> patch cures that. Is it right? The test case uses "weakref" so I' not 100% >> su

Re: Turn complete to incomplete types in free_lang_data

On Mon, 29 Oct 2018, Jan Hubicka wrote: > Hi, > this is cleaner version of the patch. During weekend I did some tests with > firefox, libreoffice and gcc builds and it seems to work well. For firefox > it reaches almost linear scalability of the ltrans files (they are 1.9GB, > after increasing nu

Re: Ping: [PATCH, testsuite]: check for weak support

> On Oct 30, 2018, at 10:17 AM, Jeff Law wrote: > > On 10/30/18 6:55 AM, Paul Koning wrote: >> Ping. Ok to commit? >> >> paul >> >>> On Oct 25, 2018, at 2:57 PM, Paul Koning wrote: >>> >>> I ran into a failures due to no weak symbol support in my target. This >>> patch cures that.

[PATCH] PR libstdc++/87784 fix dynamic_bitset::push_back

Previously the _M_Nb member was incremented before calling _M_unchecked_set which meant that the bit being set was out of bounds. It either set the wrong bit in an allocated word, or accessed beyond the end of the allocated memory in the _M_w vector. The fix for the bug is to update the _M_Nb memb

[PATCH] PR libstdc++/87809 avoid invalid expressions in exception specifications

If the allocator isn't default constructible then checking if the default constructor throws in an exception specification makes the declaration invalid. Use the type trait instead. PR libstdc++/87809 * include/bits/forward_list.h (_Fwd_list_impl::_Fwd_list_impl()): Use tr

[PATCH v2] S/390: Allow LARL of literal pool entries

Bootstrapped and regtested on s390x-redhat-linux. Changes since v1: * Removed unnecessary gen_rtx_CONST call. * UNSPEC_LTREF are now omitted for all relatively addressed pool entries, and not only those which occur in LARL-like patterns. r265490 allowed the compiler to choose in a more flexible

Re: [PATCH] Fix bug 86293

On 10/29/18 10:39 PM, Nicholas Krause wrote: > This fixes the bug on the gcc bugzilla with id, 86293. Basically > a variable is undefined in certain build configuration scentarios > and must be enabled with the attribute marco and the flag, unused > for it to avoid this build error. Build and regt

Re: [PATCH] S/390: Allow LARL of literal pool entries

Ilya Leoshkevich wrote: > Am 29.10.2018 um 19:45 schrieb Ulrich Weigand : > > > This is true. But something else must still be going on here. Note that > > many other instruction patterns might contain constant pool addresses, > > since they are accepted e.g. by the 'b' constraint. In all of tho

Re: [doc PATCH] clarify attribute optimize and target syntax

On 10/25/18 12:35 PM, Martin Sebor wrote: > While testing the optimize and target attributes and comparing > the results to what the manual describes I noticed that some > syntactic forms aren't fully documented for both attributes. > Specifically, the optimize attribute doesn't mention that each >

Re: [PATCH][rs6000] use index form addresses more often for ldbrx/stdbrx

I had to make one more change to make this actually work. In rs6000_force_indexed_or_indirect_mem() it was necessary to return the updated rtx. Bootstrap/regtest passes on ppc64le (power7, power9), ok for trunk? Thanks! Aaron 2018-10-30 Aaron Sawdey * config/rs6000/rs6000.md (bswa

[C++ Patch] Improve locations in flexible array members diagnostic

Hi, today I noticed quite a few additional places where we can exploit declarator->id_loc, the below are the first bits. Tested x86_64-linux. Thanks, Paolo. // /cp 2018-10-30 Paolo Carlini * decl.c (grokdeclarator): Use declarator->id_loc in diagnostic

Re: [PATCH] detect missing nuls in address of const char (PR 87756)

On 10/29/18 5:51 PM, Martin Sebor wrote: > The missing nul detection fails when the argument of the %s or > similar sprintf directive is the address of a non-nul character > constant such as in: > >   const char c = 'a'; >   int f (void) >   { > return snprintf (0, 0, "%s", &c); >   } > > Thi

Re: [PATCH, GCC/ARM] Fix PR87374: ICE with -mslow-flash-data and -mword-relocations

On Fri, Oct 5, 2018 at 5:50 PM Thomas Preudhomme wrote: > > Hi Ramana and Kyrill, > > I've reworked the patch to add some documentation of the option > conflict and reworked the -mword-relocation logic slightly to set the > variable explicitely in PIC mode rather than test for PIC and word > reloc

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

On Tue, Oct 30, 2018 at 08:26:00PM +0900, Stafford Horne wrote: > On Mon, Oct 29, 2018 at 04:42:43PM +, Richard Henderson wrote: > > On 10/29/18 4:34 PM, Segher Boessenkool wrote: > > > Is there some better documentation available? This is what google found > > > for me. I would have like bet

Re: [PATCH] detect missing nuls in address of const char (PR 87756)

On 10/30/2018 09:27 AM, Jeff Law wrote: On 10/29/18 5:51 PM, Martin Sebor wrote: The missing nul detection fails when the argument of the %s or similar sprintf directive is the address of a non-nul character constant such as in: const char c = 'a'; int f (void) { return snprintf (0, 0

Re: [C++ Patch] Improve locations in flexible array members diagnostic

OK. On Tue, Oct 30, 2018 at 11:23 AM Paolo Carlini wrote: > > Hi, > > today I noticed quite a few additional places where we can exploit > declarator->id_loc, the below are the first bits. Tested x86_64-linux. > > Thanks, Paolo. > > // >

Re: [PATCH] detect missing nuls in address of const char (PR 87756)

On 10/30/18 9:44 AM, Martin Sebor wrote: > On 10/30/2018 09:27 AM, Jeff Law wrote: >> On 10/29/18 5:51 PM, Martin Sebor wrote: >>> The missing nul detection fails when the argument of the %s or >>> similar sprintf directive is the address of a non-nul character >>> constant such as in: >>> >>>   co

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

On 10/30/18 12:18 PM, Stafford Horne wrote: > OK, I was just being lazy allowing the spill. Do you think the split/expand > would be an RTL using left shift / right shift? Can you think of something > more clever? Since "real" hardware does not usually support shifts with an > immediate we will

[RFT PATCH, middle end]: Fix PR58372, internal compiler error: ix86_compute_frame_layout

Hello! Function calls, generated directly through emit_library_call (for the testcase from PR the compiler builds a call to _Unwind_SjLj_Register via sjlj_emit_function_enter) miss a whole lot of stack realignmnet setup. There is an update to crtl->preferred_stack_boundary present, but several upd

Re: [PATCH v3 3/3] or1k: gcc: initial support for openrisc

On Tue, Oct 30, 2018 at 09:49:18PM +0900, Stafford Horne wrote: > Hello, > > On Sun, Oct 28, 2018 at 05:54:47PM -0500, Segher Boessenkool wrote: > > Yes, like that. It also easily can handle the other combos (those with > > STACK_POINTER), and it is easier if you have to switch FRAME_GROWS_DOWNWA

Re: [PATCH] detect missing nuls in address of const char (PR 87756)

On 10/30/2018 09:54 AM, Jeff Law wrote: On 10/30/18 9:44 AM, Martin Sebor wrote: On 10/30/2018 09:27 AM, Jeff Law wrote: On 10/29/18 5:51 PM, Martin Sebor wrote: The missing nul detection fails when the argument of the %s or similar sprintf directive is the address of a non-nul character const

Re: [PATCH][rs6000] use index form addresses more often for ldbrx/stdbrx

On Tue, Oct 30, 2018 at 10:22:48AM -0500, Aaron Sawdey wrote: > I had to make one more change to make this actually work. In > rs6000_force_indexed_or_indirect_mem() it was necessary to > return the updated rtx. Yes, that probably work better ;-) > Bootstrap/regtest passes on ppc64le (power7, pow

Re: [PATCH] S/390: Allow LARL of literal pool entries

> Am 30.10.2018 um 16:20 schrieb Ulrich Weigand : > > Ilya Leoshkevich wrote: >> Am 29.10.2018 um 19:45 schrieb Ulrich Weigand : >> >>> This is true. But something else must still be going on here. Note that >>> many other instruction patterns might contain constant pool addresses, >>> since

[PATCH/AARCH64] Add OcteonTX for -mcpu=

Hi all, There was a name change of the Products, ThunderX T81 and ThunderX T83 to OcteonTX family name. This change was done a few years ago but I had not submmitted the change at that time. This is also the first patch in a series to add OcteonTX 2 support to GCC. OK? Bootstrapped and tested

Re: [PATCH, testsuite, c-compat] Handle another c/l option not recognised by older GCC or clang.

On Oct 29, 2018, at 12:53 PM, Iain Sandoe wrote: > > When using ALT_CC/CXX_UNDER_TEST in the compat/struct-layout-1 tests, the c/l > options provided to the “alt” compiler need to avoid latest and greatest GCC > capability. The patch tests to see if the ‘alt’ compiler can handle > -fno-diagno

Re: [PATCH/AARCH64] Add OcteonTX for -mcpu=

On 30/10/2018 17:06, Andrew Pinski wrote: > Hi all, > There was a name change of the Products, ThunderX T81 and ThunderX > T83 to OcteonTX family name. This change was done a few years ago but > I had not submmitted the change at that time. This is also the first > patch in a series to add Octe

Re: [PATCH] S/390: Allow LARL of literal pool entries

Ilya Leoshkevich wrote: > Am 30.10.2018 um 16:20 schrieb Ulrich Weigand : > > Not sure that this is fully correct either. *Some* instructions, like > > e.g. floating-point loads, do not accept relative operands. And even > > for the relative loads that exist, there may be slightly different > > r

Re: [PATCH v2] S/390: Allow LARL of literal pool entries

Ilya Leoshkevich wrote: > @@ -8223,6 +8237,18 @@ find_constant_pool_ref (rtx x, rtx *ref) >&& XINT (x, 1) == UNSPECV_POOL_ENTRY) > return; > > + if (SYMBOL_REF_P (x) > + && CONSTANT_POOL_ADDRESS_P (x) > + && s390_symbol_larl_p (x)) > +{ > + if (*ref == NULL_RTX)

[PATCH 1/2] asm qualifiers (PR55681)

PR55681 observes that currently only one qualifier is allowed for inline asm, so that e.g. "volatile asm" is allowed, "const asm" is also okay (with a warning), but "const volatile asm" gives an error. Also "const const asm" is an error (while "const const int" is okay for C), "goto" has to be las

[PATCH 0/2] asm qualifiers (PR55681) and asm input

Hi! This is the same "asm input" patch as before, but now preceded by a patch that makes all orderings of volatile/goto/inline valid, also the other type qualifiers for C, and also repetitions for C. Tested on powerpc64-linux {-m32,-m64}. Is this okay for trunk? Segher gcc/c/c-parser.c

[PATCH 2/2] asm inline

The Linux kernel people want a feature that makes GCC pretend some inline assembler code is tiny (while it would think it is huge), so that such code will be inlined essentially always instead of essentially never. This patch lets you say "asm inline" instead of just "asm", with the result that th

Re: [PATCH 2/2] asm inline

On Tue, Oct 30, 2018 at 05:30:34PM +, Segher Boessenkool wrote: > --- a/gcc/c/c-typeck.c > +++ b/gcc/c/c-typeck.c > @@ -10064,7 +10064,7 @@ build_asm_stmt (tree cv_qualifier, tree args) > are subtly different. We use a ASM_EXPR node to represent this. */ > tree > build_asm_expr (locatio

Re: Fix D compilation on Solaris

On Tue, 30 Oct 2018 at 14:13, Rainer Orth wrote: > > Rainer Orth writes: > > > * On sparc, I didn't get that far, unfortunately: as I mentioned, many > > compilations die with SIGBUS: > > > > libtool: compile: /var/gcc/regression/trunk/11.5-gcc/build/./gcc/gdc > > -B/var/gcc/regression/trunk/

[PATCH] xfail ira-shrink-wrap-prep tests (PR87708)

After r265398, the ira-shrinkwrap-prep-[12].c tests fail on all targets, because the IRA feature tested can only move hard registers down, and we no longer have hard registers for the function parameters at this stage. Is this okay for trunk? 2018-10-30 Segher Boessenkool gcc/testsuite/

Remove duplicate line in gcov's output

...coming from a duplicate line in gcov's source code. Tested on x86_64-suse-linux, applied on mainline as obvious. 2018-10-30 Eric Botcazou * gcov.c (output_lines): Remove duplicate line. -- Eric BotcazouIndex: gcov.c ===

Re: [PATCH v2] S/390: Allow LARL of literal pool entries

> Am 30.10.2018 um 18:22 schrieb Ulrich Weigand : > > Ilya Leoshkevich wrote: > >> @@ -8223,6 +8237,18 @@ find_constant_pool_ref (rtx x, rtx *ref) >> && XINT (x, 1) == UNSPECV_POOL_ENTRY) >> return; >> >> + if (SYMBOL_REF_P (x) >> + && CONSTANT_POOL_ADDRESS_P (x) >> + && s

[patch, fortran] Fix PR 85896, type confusion with min and max

Hello world, the attached patchlet fixes a rejects-valid bug by simply ignoring the type for max and min during simplification. This is correct because setting the type of a generic intrinsic function has no effect. It is a rare pleasure to fix a bug by removing code only :-) Regression-tested

Re: [PATCH] xfail ira-shrink-wrap-prep tests (PR87708)

On 10/30/18 11:59 AM, Segher Boessenkool wrote: > After r265398, the ira-shrinkwrap-prep-[12].c tests fail on all > targets, because the IRA feature tested can only move hard registers > down, and we no longer have hard registers for the function parameters > at this stage. > > Is this okay for tr

[PATCH 1/4] [og8] Attach / Detach generic infrastructure

As mentioned here , this patch series adds support for the new attach / detach clauses introduced in OpenACC 2.6 to the C and C++ front ends. There is one notable difference between this patch and the one I posted for trunk. This patch twea

[PATCH 2/4] [og8] Attach / Detach C FE changes

As noted here , this patch adds support for attach and detach in the C front end. The only major difference between this and the trunk patch is that OG8 supports the acc routine bind clause, do the trunk patch didn't apply cleanly. Other tha

[PATCH 3/4] [og8] Attach / Detach C++ FE changes

As noted here this patch adds support for attach and detach in the C++ front end. Unlike trunk, OG8 has some preliminary support for the this pointer. Consequently, finish_omp_clauses had to take care of a couple more cases in order to get

Re: [PATCH] avoid -Wnonnull for printf format in dead code (PR 87041)

On 10/29/18 3:59 PM, Martin Sebor wrote: > PR 87041 - -Wformat "reading through null pointer" on unreachable > code is a complaint about -Wformat false positives due to null > arguments to %s directives in unreachable printf calls.  The warning > is issued by the front end, too early to know whethe

Re: [AArch64] Add Saphira pipeline description.

On Tue, Oct 30, 2018 at 05:12:58AM -0500, Sameera Deshpande wrote: > On Fri, 26 Oct 2018 at 13:33, Sameera Deshpande > wrote: > > > > Hi! > > > > Please find attached the patch to add a pipeline description for the > > Qualcomm Saphira core. It is tested with a bootstrap and make check, > > with

[PATCH 4/4] [og8] Attach / Detach compiler tests

This patch introduces a couple of compiler tests for the OpenACC attach and detach clauses. I've committed it to openacc-gcc-8-branch. Cesar 2018-10-30 Cesar Philippidis gcc/testsuite/ * c-c++-common/goacc/mdc-1.c: New test. * c-c++-common/goacc/mdc-2.c: New test. * g++.dg/goacc/mdc.C: Ne

Re: [PATCH, testsuite, c-compat] Handle another c/l option not recognised by older GCC or clang.

On 10/29/18 1:53 PM, Iain Sandoe wrote: > Hi > > When using ALT_CC/CXX_UNDER_TEST in the compat/struct-layout-1 tests, the c/l > options provided to the “alt” compiler need to avoid latest and greatest GCC > capability. The patch tests to see if the ‘alt’ compiler can handle > -fno-diagnostics

Re: Turn complete to incomplete types in free_lang_data

Hi, this is variant I re-tested and comitted. It goes by adding the type to worklist - it is very hard to debug ordering issues in free lang data so I think it is more robust to avoid introducing more surprises and we will definitly want to also simplify function types eventually. I am now re

Re: [PATCH] Provide extension hint for aarch64 target (PR driver/83193).

On Thu, Oct 25, 2018 at 05:53:22AM -0500, Martin Liška wrote: > On 10/24/18 7:48 PM, Martin Sebor wrote: > > On 10/24/2018 03:52 AM, Martin Liška wrote: > >> On 10/23/18 6:31 PM, Martin Sebor wrote: > >>> On 10/22/2018 07:05 AM, Martin Liška wrote: > On 10/16/18 6:57 PM, James Greenhalgh wrote

Re: [patch, fortran] Fix PR 85896, type confusion with min and max

On Tue, Oct 30, 2018 at 8:57 PM Thomas Koenig wrote: > Hello world, > > the attached patchlet fixes a rejects-valid bug by simply ignoring the > type for max and min during simplification. This is correct > because setting the type of a generic intrinsic function has > no effect. > > It is a rar

[PATCH, d] Disable D on systems where it is known not to work.

Hi, This turns off D front-end where there's been reported bootstrap problems that need further investigation. Also added a configure.tgt for libphobos to allow enabling for targets where there's known good runtime support backed by existing continuous integration. For both, this can be overridd

Re: [patch] various OpenACC reduction enhancements - ME and nvptx changes

On 10/5/18 07:07, Tom de Vries wrote: > On 6/29/18 8:19 PM, Cesar Philippidis wrote: >> The attached patch includes the nvptx and GCC ME reductions enhancements. >> >> Is this patch OK for trunk? It bootstrapped / regression tested cleanly >> for x86_64 with nvptx offloading. >> > > These need fix

Re: C++ PATCH to implement C++20 P0892R2 - explicit(bool) [v4]

On 10/29/18 6:15 PM, Marek Polacek wrote: On Wed, Oct 24, 2018 at 02:55:14PM -0400, Jason Merrill wrote: On 10/12/18 12:32 PM, Marek Polacek wrote: + EXPLICIT_SPECIFIER is used in case the explicit-specifier, if any, has + value-dependent expression. */ static void cp_parser_decl_speci

Re: [PATCH, AArch64 v2 01/11] aarch64: Simplify LSE cas generation

On Tue, Oct 02, 2018 at 11:19:05AM -0500, Richard Henderson wrote: > The cas insn is a single insn, and if expanded properly need not > be split after reload. Use the proper inputs for the insn. OK. Thanks, James > > * config/aarch64/aarch64.c (aarch64_expand_compare_and_swap): > F

Re: [PATCH, d] Disable D on systems where it is known not to work.

On Okt 30 2018, Iain Buclaw wrote: > This turns off D front-end where there's been reported bootstrap > problems that need further investigation. Also added a configure.tgt > for libphobos to allow enabling for targets where there's known good > runtime support backed by existing continuous inte

Re: [PATCH, d] Disable D on systems where it is known not to work.

On Tue, 30 Oct 2018 at 20:50, Andreas Schwab wrote: > > On Okt 30 2018, Iain Buclaw wrote: > > > This turns off D front-end where there's been reported bootstrap > > problems that need further investigation. Also added a configure.tgt > > for libphobos to allow enabling for targets where there's

Re: [PATCH, AArch64 v2 02/11] aarch64: Improve cas generation

On Tue, Oct 02, 2018 at 11:19:06AM -0500, Richard Henderson wrote: > Do not zero-extend the input to the cas for subword operations; > instead, use the appropriate zero-extending compare insns. > Correct the predicates and constraints for immediate expected operand. OK, modulo two very dull style

Re: [PATCH, AArch64 v2 03/11] aarch64: Improve swp generation

On Tue, Oct 02, 2018 at 11:19:07AM -0500, Richard Henderson wrote: > Allow zero as an input; fix constraints; avoid unnecessary split. OK. James > > * config/aarch64/aarch64.c (aarch64_emit_atomic_swap): Remove. > (aarch64_gen_atomic_ldop): Don't call it. > * config/aarch64/at

Re: [PATCH, AArch64 v2 04/11] aarch64: Improve atomic-op lse generation

On Tue, Oct 02, 2018 at 11:19:08AM -0500, Richard Henderson wrote: > Fix constraints; avoid unnecessary split. Drop the use of the atomic_op > iterator in favor of the ATOMIC_LDOP iterator; this is simplier and more > logical for ldclr aka bic. OK. Thanks, James > > * config/aarch64/aarc

Re: [PATCH, AArch64 v2 05/11] aarch64: Emit LSE st instructions

On Tue, Oct 02, 2018 at 11:19:09AM -0500, Richard Henderson wrote: > When the result of an operation is not used, we can ignore the > result by storing to XZR. For two of the memory models, using > XZR with LD has a preferred assembler alias, ST. ST has different semantics to LD, in particular, S

V2 [PATCH] i386: Use scalar operand in SF/DF/SI/DI vec_dup patterns

On Mon, Oct 29, 2018 at 2:02 PM Uros Bizjak wrote: > > On Sat, Oct 27, 2018 at 8:03 AM H.J. Lu wrote: > > > > Use scalar operand in SF/DF/SI/DI vec_dup patterns which enables combiner > > to generate > > > > (set (reg:V8SF 84) > > (vec_duplicate:V8SF (mem/c:SF (symbol_ref:DI ("y") > > >

Re: [C++ Patch] PR 84644 ("internal compiler error: in warn_misplaced_attr_for_class_type, at cp/decl.c:4718")

On 10/26/18 2:02 PM, Paolo Carlini wrote: On 26/10/18 17:18, Jason Merrill wrote: On Fri, Oct 26, 2018 at 4:52 AM Paolo Carlini wrote: On 24/10/18 22:41, Jason Merrill wrote: On 10/15/18 12:45 PM, Paolo Carlini wrote: && ((TREE_CODE (declspecs->type) != TYPENAME_TYPE +   && TREE

Re: [PATCH, AArch64 v2 06/11] Add visibility to libfunc constructors

This one needs some other reviewers copied in, who may have missed that it is not an AARch64 only patch (it looks fine to me). James On Tue, Oct 02, 2018 at 11:19:10AM -0500, Richard Henderson wrote: > * optabs-libfuncs.c (build_libfunc_function_visibility): > New, split out from... >

Re: [PATCH, AArch64 v2 09/11] aarch64: Force TImode values into even registers

On Tue, Oct 02, 2018 at 11:19:13AM -0500, Richard Henderson wrote: > The LSE CASP instruction requires values to be placed in even > register pairs. A solution involving two additional register > classes was rejected in favor of the much simpler solution of > simply requiring all TImode values to

[PATCH] use MAX_OFILE_ALIGNMENT to validate attribute aligned (PR 87795)

Bug 87795 - Excessive alignment permitted for functions and labels points out that the handler for attribute aligned makes it possible for unsupported alignments to be accepted by the front end only to be either rejected later on by some targets for variables, or to cause an ICE for overaligned fu

Avoid tests failures in C++98

Running some tests in C++98 show that the error checked by following tests are those of the C++11 mode. This patch add target c++11 so that those tests are ignored in previous mode.     * testsuite/23_containers/deque/requirements/dr438/assign_neg.cc:     Add target c++11.     * testsuite/23

Re: [PATCH] use MAX_OFILE_ALIGNMENT to validate attribute aligned (PR 87795)

On 10/30/18 3:40 PM, Martin Sebor wrote: > Bug 87795 - Excessive alignment permitted for functions and labels > points out that the handler for attribute aligned makes it possible > for unsupported alignments to be accepted by the front end only to > be either rejected later on by some targets for 

Re: Avoid tests failures in C++98

On 30/10/18 22:42 +0100, François Dumont wrote: Running some tests in C++98 show that the error checked by following tests are those of the C++11 mode. This patch add target c++11 so that those tests are ignored in previous mode.     * testsuite/23_containers/deque/requirements/dr438/assign_

LTO partitioning performance & increase default number of partitions

Hi, this patch increases lto-partitions to 128. This makes ltrans.o file sizes to grow from 458MB to 651MB which is still not perfect but a lot better than prevoiusly. On firefox the growth is smaller (only about 10%) which is probably caused by the "unified build" they use where they merge multi

  1   2   >