[PATCH] Fix PR69771, bogus CONST_INT during shift expansion

I am testing the following patch which fixes PR69771 where the code doesn't match the comment before it. We get to expand a QImode << QImode shift but the shift amount was of type int and thus it was expanded as SImode constant. Then /* In case the insn wants input operands in modes

Re: [patch, Fortran] Fix PR 60526, variable name has already been declared as a type

Hi all, it wasn't my intention to start such a big discussion for such a small thing. Please stop this academic battle and get back to the issue at hand: Thomas is examining a symbol, that - has come through the scanner, i.e., it adheres to the rules of gfortran, especially it is known to be

Re: [patch, Fortran] Fix PR 60526, variable name has already been declared as a type

Hi Janne, [std::string] As we're supposed to be C++ nowadays, why aren't we using that? My reason is simple: I know C and Fortran. I hardly know C++, and I don't want to learn it for the sake of some largely irrelevant micro-optimizations. We should restrict C++ usage to those cases where

Re: [PATCH, reload] PRE_INC with invalid hard reg

On 02/11/2016 08:27 PM, Alan Modra wrote: On Thu, Feb 11, 2016 at 03:29:05PM +0100, Bernd Schmidt wrote: On 02/11/2016 10:45 AM, Alan Modra wrote: Due to uses elsewhere in vsx instructions, reload chooses to put psuedo 185 in fr31, which can't be used as a base register in the following:

Re: [PATCH] PR driver/69265: improved suggestions for various misspelled options

On 02/11/2016 08:43 AM, David Malcolm wrote: On Thu, 2016-02-11 at 10:16 +0100, Richard Biener wrote: On Wed, Feb 10, 2016 at 5:25 PM, Bernd Schmidt wrote: On 02/09/2016 09:44 PM, David Malcolm wrote: This is a bug in a new feature, so it isn't a regression as such, but

Re: [PATCH] Fix PR69771, bogus CONST_INT during shift expansion

On Fri, Feb 12, 2016 at 11:23:26AM +0100, Richard Biener wrote: > > I am testing the following patch which fixes PR69771 where the code > doesn't match the comment before it. We get to expand a QImode << QImode > shift but the shift amount was of type int and thus it was expanded > as SImode

Re: [PR66726] Fixe regression caused by Factor conversion out of COND_EXPR

> This causes LTO/PGO bootstrap on ppc64le to ICE all over the place: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69781 And a comparison failure with -enable-checking=yes,rtl on x86-64/Linux: Comparing stages 2 and 3 warning: gcc/cc1plus-checksum.o differs warning: gcc/cc1-checksum.o differs

Re: [RFC] [P2] [PR tree-optimization/33562] Lowering more complex assignments.

On Fri, Feb 12, 2016 at 12:53 AM, Jeff Law wrote: > > So I've never thought much about our Complex support and I don't have a lot > of confidence in the coverage for our testsuite for these changes. So I'd > really appreciate someone with more experience thinking about this issue

Re: [patch, Fortran] Fix PR 60526, variable name has already been declared as a type

On Fri, Feb 12, 2016 at 12:16 PM, Andre Vehreschild wrote: > Hi all, > > it wasn't my intention to start such a big discussion for such a small > thing. Please stop this academic battle and get back to the issue at > hand: > > Thomas is examining a symbol, that > > - has come

[PATCH] Fix PR69776, FRE/PRE not honoring middle-end memory model

FRE/PREs redundant store removal code doesn't honor the middle-end memory model which says that all stores change the dynamic type of the affected memory region. So it removed the second 'int' store in MEM[(int *)p_3] = 1; MEM[(double *)p_3] = 0.0; MEM[(int *)p_3] = 1; which is not valid

Re: [PING^3][PATCH, 12/16] Handle acc loop directive

On 26/01/16 13:49, Jakub Jelinek wrote: On Tue, Jan 26, 2016 at 01:38:39PM +0100, Tom de Vries wrote: Ping^3. ( https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01089.html ) First of all, I wonder if it wouldn't be far easier to handle these during gimplification rather than during omp expansion

Re: [PATCH] Fix another ipa-split caused ICE (PR ipa/69241)

On Thu, 11 Feb 2016, Jakub Jelinek wrote: > On Thu, Feb 11, 2016 at 10:22:24AM +0100, Richard Biener wrote: > > The other option is to simply not split the function in this case. > > Here is a better fix (but it needs the other patch I've sent, so that > what is return_bb stays the same). > >

Re: Fix PR69752, insn with REG_INC being removed as equiv_init insn

On 12/02/16 07:43, Jeff Law wrote: On 02/11/2016 06:28 PM, Bernd Schmidt wrote: This seems fairly straightforward: (insn 213 455 216 6 (set (reg:SI 266) (mem/u/c:SI (post_inc:SI (reg/f:SI 267)) [4 S4 A32])) 748 {*thumb1_movsi_insn} (expr_list:REG_EQUAL (const_int -1044200508

Re: Fix c/69522, memory management issue in c-parser

On 02/12/2016 02:26 PM, Marek Polacek wrote: On Fri, Feb 12, 2016 at 02:17:19PM +0100, Andreas Schwab wrote: FAIL: gcc.dg/pr69522.c (test for excess errors) Excess errors: /daten/aranym/gcc/gcc-20160212/gcc/testsuite/gcc.dg/pr69522.c:2:8: error: struct has no members [-Wpedantic] /daten/aranym

Re: [PATCH] Fix PR69771, bogus CONST_INT during shift expansion

On Fri, Feb 12, 2016 at 01:50:08PM +0100, Richard Biener wrote: > > - mode1 = GET_MODE (xop1) != VOIDmode ? GET_MODE (xop1) : mode; > > - if (xmode1 != VOIDmode && xmode1 != mode1) > > + mode1 = GET_MODE (xop1); > > + if (xmode1 != mode1) > > { > >xop1 = convert_modes (xmode1,

Re: AW: Wonly-top-basic-asm

On 02/12/2016 08:05 AM, David Wohlferd wrote: Actually, it was my intent that this apply to v6. It's not like there is a significant change here. We're documenting long-time behavior, and adding a (disabled) warning. The doc patch (minus mentioning the warning) could go in now, but for

Re: Fix PR69752, insn with REG_INC being removed as equiv_init insn

On 12/02/16 07:43, Jeff Law wrote: On 02/11/2016 06:28 PM, Bernd Schmidt wrote: This seems fairly straightforward: (insn 213 455 216 6 (set (reg:SI 266) (mem/u/c:SI (post_inc:SI (reg/f:SI 267)) [4 S4 A32])) 748 {*thumb1_movsi_insn} (expr_list:REG_EQUAL (const_int -1044200508

Re: [PATCH] Spelling fixes - behaviour and neighbour

> While working on the -Waddress fix I've posted earlier today, I've noticed > that the C and C++ FE disagree on the spelling - C uses US english spelling, > while C++ uses UK english spelling. > This patch switches to US english spelling of these 2 words, in > diagnostics, documentation and

Re: [PATCH] Fix ipa-split handling of clobbers and debug stmts in return_bb (PR ipa/68672)

On Thu, 11 Feb 2016, Jakub Jelinek wrote: > Hi! > > While the cgraph versioning code is able to deal with clobber stmts that > refer to SSA_NAMEs set by basic blocks not split into the versioned > function, and similarly with debug stmts (clobbers refererring to those > are removed and debug

Re: [PATCH] Fix PR69771, bogus CONST_INT during shift expansion

On 02/12/2016 11:46 AM, Richard Biener wrote: On Fri, 12 Feb 2016, Jakub Jelinek wrote: On Fri, Feb 12, 2016 at 11:23:26AM +0100, Richard Biener wrote: I am testing the following patch which fixes PR69771 where the code doesn't match the comment before it. We get to expand a QImode <<

Re: [PATCH] Fix PR69771, bogus CONST_INT during shift expansion

On Fri, 12 Feb 2016, Jakub Jelinek wrote: > On Fri, Feb 12, 2016 at 01:15:11PM +0100, Bernd Schmidt wrote: > > >Ah, indeed looks like a dup. Let's go with your version which had > > >feedback from Bernd already. Might want to add my testcase (w/o the > > >runtime outcome test). > > > >

Re: [PATCH] Fix PR69771, bogus CONST_INT during shift expansion

On Fri, 12 Feb 2016, Richard Biener wrote: > On Fri, 12 Feb 2016, Jakub Jelinek wrote: > > > On Fri, Feb 12, 2016 at 01:15:11PM +0100, Bernd Schmidt wrote: > > > >Ah, indeed looks like a dup. Let's go with your version which had > > > >feedback from Bernd already. Might want to add my testcase

[PATCH, CHKP, committed] Fix PR middle-end/69729

Hi, This patch fixes instrumentation thunk recognition condition in lto_output. This avoids missing required thunks in ltrans modules. Bootstrapped and regtested on x86_64-pc-linux-gnu. Committed to trunk. Thanks, Ilya -- gcc/ 2016-02-12 Ilya Enkovich PR

Re: Fix c/69522, memory management issue in c-parser

FAIL: gcc.dg/pr69522.c (test for excess errors) Excess errors: /daten/aranym/gcc/gcc-20160212/gcc/testsuite/gcc.dg/pr69522.c:2:8: error: struct has no members [-Wpedantic] /daten/aranym/gcc/gcc-20160212/gcc/testsuite/gcc.dg/pr69522.c:9:8: error: ISO C forbids empty initializer braces [-Wpedantic

Re: Fix c/69522, memory management issue in c-parser

On Fri, Feb 12, 2016 at 02:17:19PM +0100, Andreas Schwab wrote: > FAIL: gcc.dg/pr69522.c (test for excess errors) > Excess errors: > /daten/aranym/gcc/gcc-20160212/gcc/testsuite/gcc.dg/pr69522.c:2:8: error: > struct has no members [-Wpedantic] > /daten/aranym/gcc/gcc-20160212/gcc/t

Re: [PATCH, reload] PRE_INC with invalid hard reg

On 02/12/2016 04:27 AM, Alan Modra wrote: I don't understand this comment. If we're pushing a reload of the inner reg, then the SECONDARY_MEMORY_NEEDED code in push_reload will fire. Why then should there be any need to do anything special in find_reloads_address_1 regarding secondary memory?

Re: [PATCH] Fix PR69771, bogus CONST_INT during shift expansion

On Fri, Feb 12, 2016 at 01:15:11PM +0100, Bernd Schmidt wrote: > >Ah, indeed looks like a dup. Let's go with your version which had > >feedback from Bernd already. Might want to add my testcase (w/o the > >runtime outcome test). > > Actually, Richard I was just looking at Jakub's second patch

[PATCH, MPX, committed] Fix warning in MPX effective target test

Hi, This patch fixes a warning in test used for effective MPX target check. Fix allows to use test with g++. Bootsrapped and tested on x86_64-pc-linux-gnu. Applied to trunk. Thanks, Ilya -- gcc/testsuite/ 2016-02-11 Ilya Enkovich * lib/mpx-dg.exp: Fix

Re: [PATCH] Fix PR69771, bogus CONST_INT during shift expansion

On Fri, 12 Feb 2016, Jakub Jelinek wrote: > On Fri, Feb 12, 2016 at 11:23:26AM +0100, Richard Biener wrote: > > > > I am testing the following patch which fixes PR69771 where the code > > doesn't match the comment before it. We get to expand a QImode << QImode > > shift but the shift amount was

Re: [PATCH] Fix PR69771, bogus CONST_INT during shift expansion

On Fri, Feb 12, 2016 at 01:48:36PM +0100, Richard Biener wrote: > But my patch should deal with all this. > > - mode1 = GET_MODE (xop1) != VOIDmode ? GET_MODE (xop1) : mode; > - if (xmode1 != VOIDmode && xmode1 != mode1) > + mode1 = GET_MODE (xop1); > + if (xmode1 != mode1) > { >

Re: [PATCH] Fix PR69771, bogus CONST_INT during shift expansion

On Fri, Feb 12, 2016 at 02:45:40PM +0100, Richard Biener wrote: > > The case I'm worried about is if xop1 is a constant in narrower > > mode (let's say QImode), e.g. -15, unsignedp is 1, and xmode1 is > > wider. Then previously we'd zero extend it, thus get > > 0xf1, but with your patch we'll end

Re: [PATCH ARM] RFC: PR69770 -mlong-calls does not affect calls to __gnu_mcount_nc generated by -pg

On 12/02/16 15:02, Jiong Wang wrote: On 12/02/16 14:56, Charles Baylis wrote: This is encountered when building an allyesconfig Linux kernel because the Linux build system generates very large sections by partial linking a large number of object files. This causes link failures I have

[PATCH] Add testcase for ICE in assemble_integer

We've got a report that GCC is crashing when building a package on i686; there was an ICE in assemble_integer. Turned out this ICE was already fixed by r233216, so I reduced it and would like to add it to the testsuite. Tested on x86_64-linux and i686-linux, ok for trunk? 2016-02-12 Marek

Re: [PATCH] Fix PR69771, bogus CONST_INT during shift expansion

On 02/12/2016 02:47 PM, Richard Biener wrote: Another possibility, only do the convert_modes from VOIDmode for shift_optab_p's xop1, and keep doing what we've done before otherwise. That looks like a very targeted and safe fix indeed. You two can obviously go ahead and sort this out, I'll

Re: Fix c/69522, memory management issue in c-parser

On Fri, Feb 12, 2016 at 02:28:39PM +0100, Bernd Schmidt wrote: > On 02/12/2016 02:26 PM, Marek Polacek wrote: > >On Fri, Feb 12, 2016 at 02:17:19PM +0100, Andreas Schwab wrote: > >>FAIL: gcc.dg/pr69522.c (test for excess errors) > >>Excess errors: > >>/daten/a

Re: [PATCH] Fix PR69771, bogus CONST_INT during shift expansion

On Fri, 12 Feb 2016, Jakub Jelinek wrote: > On Fri, Feb 12, 2016 at 01:48:36PM +0100, Richard Biener wrote: > > But my patch should deal with all this. > > > > - mode1 = GET_MODE (xop1) != VOIDmode ? GET_MODE (xop1) : mode; > > - if (xmode1 != VOIDmode && xmode1 != mode1) > > + mode1 =

Re: Fix PR69752, insn with REG_INC being removed as equiv_init insn

On 12/02/16 13:33, Bernd Schmidt wrote: On 02/12/2016 02:18 PM, Jiong Wang wrote: PR rtl-optimization/69752 * ira.c (update_equiv_regs): When looking for more than a single SET, also take other side effects into account. Will it be better that we don't remove the insn if it has

Re: [wwwdocs] Mention flexible array type and mangling change

On Thu, Feb 11, 2016 at 02:17:43PM -0700, Martin Sebor wrote: > >>Actually, there is one other thing that might be wort mentioning > >>about flexible array members. > >> > >>The type and mangling of flexible array members has changed. While > >>in GCC 5 and prior the type of a flexible array

Re: [PR66726] Fixe regression caused by Factor conversion out of COND_EXPR

On Thu, Feb 11, 2016 at 10:18 PM, Markus Trippelsdorf wrote: > On 2016.02.08 at 09:49 -0700, Jeff Law wrote: >> On 01/18/2016 08:52 PM, Kugan wrote: >> > >> >2016-01-19 Kugan Vivekanandarajah >> > >> > PR middle-end/66726 >> > *

Re: Fix PR69752, insn with REG_INC being removed as equiv_init insn

On 02/12/2016 02:18 PM, Jiong Wang wrote: PR rtl-optimization/69752 * ira.c (update_equiv_regs): When looking for more than a single SET, also take other side effects into account. Will it be better that we don't remove the insn if it has side-effect instead of don't record the

Re: [PATCH] Fix PR69771, bogus CONST_INT during shift expansion

On Fri, 12 Feb 2016, Jakub Jelinek wrote: > On Fri, Feb 12, 2016 at 01:50:08PM +0100, Richard Biener wrote: > > > - mode1 = GET_MODE (xop1) != VOIDmode ? GET_MODE (xop1) : mode; > > > - if (xmode1 != VOIDmode && xmode1 != mode1) > > > + mode1 = GET_MODE (xop1); > > > + if (xmode1 != mode1) >

Re: [RS6000] reload_vsx_from_gprsf splitter

(Replying to multiple messages at once ...) Michael Meissner wrote: > At the present time, we do not allow DImode to go into Altivec > registers. Mostly it was due to reload complications in the power8 time frame, > where we didn't have d-form addressing for the Altivec registers and >

[PATCH ARM] RFC: PR69770 -mlong-calls does not affect calls to __gnu_mcount_nc generated by -pg

When compiling with -mlong-calls and -pg, calls to the __gnu_mcount_nc function are not generated as long calls. This is encountered when building an allyesconfig Linux kernel because the Linux build system generates very large sections by partial linking a large number of object files. This

Re: [PATCH ARM] RFC: PR69770 -mlong-calls does not affect calls to __gnu_mcount_nc generated by -pg

On 12/02/16 14:56, Charles Baylis wrote: This is encountered when building an allyesconfig Linux kernel because the Linux build system generates very large sections by partial linking a large number of object files. This causes link failures I have tried latest BFD linker? I suspect the

New Esperanto PO file for 'cpplib' (version 6.1-b20160131)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Esperanto team of translators. The file is available at: http://translationproject.org/latest/cpplib/eo.po (This file,

[PATCH] Fix ICE when expanding incorrect shift counts (PR rtl-optimization/69764, take 2)

On Fri, Feb 12, 2016 at 02:08:53AM +0100, Bernd Schmidt wrote: > Isn't the problem just that shifts are unusual as binops, in that the two > operands can have different modes? We have the appropriate mode for the > shift count in xmode1, so I think we should just always rebuild a CONST_INT > in

Re: libgcc: On AIX, increase chances to find landing pads for exceptions

On 02/10/2016 02:27 PM, David Edelsohn wrote: > On Wed, Feb 10, 2016 at 1:52 AM, Michael Haubenwallner > wrote: >> >> On 02/08/2016 02:59 PM, David Edelsohn wrote: >>> Runtime linking is disabled by default on AIX, and I disabled it for >>> libstdc++. >>

Re: [RFC] [P2] [PR tree-optimization/33562] Lowering more complex assignments.

On 02/12/2016 02:04 AM, Richard Biener wrote: So what am I missing here? Is there any kind of aliasing issues I need to be aware of? Any other dragons lurking? I think what you are missing is that you'll "optimize" _Complex double x, y; void foo (void) { x = y; } then but dependent on

Re: bswap PRs 69714, 67781

On 02/12/2016 09:28 AM, Bernd Schmidt wrote: PR69714 is an issue where the bswap pass makes an incorrect transformation on big-endian targets. The source has a 32-bit bswap, but PA doesn't have a pattern for that. Still, we recognize that there is a 16-bit bswap involved, and generate code for

Re: [Patch X86_64]: Minor changes to znver1 pipe reservations.

On Fri, Feb 12, 2016 at 5:31 PM, Kumar, Venkataramanan wrote: > Hi Maintainers, > > Below patch does some minor changes to pipe reservations in znver1.md. > GCC bootstrap completed. > > GCC regression testing underway. Ok for trunk if the testing passes? > > >

[Patch X86_64]: Minor changes to znver1 pipe reservations.

Hi Maintainers, Below patch does some minor changes to pipe reservations in znver1.md. GCC bootstrap completed. GCC regression testing underway. Ok for trunk if the testing passes? ChangeLog - 2016-02-12  Venkataramanan Kumar      * 

Re: [PATCH] Fix PR69771, bogus CONST_INT during shift expansion

So do you prefer e.g. following? Bootstrapped/regtested on x86_64-linux and i686-linux. - mode1 = GET_MODE (xop1) != VOIDmode ? GET_MODE (xop1) : mode; + mode1 = (GET_MODE (xop1) != VOIDmode || canonicalize_op1) + ? GET_MODE (xop1) : mode; Placement of parentheses is wrong for

Re: [PATCH] Add testcase for ICE in assemble_integer

On 02/12/2016 03:08 PM, Marek Polacek wrote: We've got a report that GCC is crashing when building a package on i686; there was an ICE in assemble_integer. Turned out this ICE was already fixed by r233216, so I reduced it and would like to add it to the testsuite. Tested on x86_64-linux and

bswap PRs 69714, 67781

PR69714 is an issue where the bswap pass makes an incorrect transformation on big-endian targets. The source has a 32-bit bswap, but PA doesn't have a pattern for that. Still, we recognize that there is a 16-bit bswap involved, and generate code for that - loading the halfword at offset 2 from

Re: [PATCH ARM] RFC: PR69770 -mlong-calls does not affect calls to __gnu_mcount_nc generated by -pg

On 12/02/16 14:56, Charles Baylis wrote: > When compiling with -mlong-calls and -pg, calls to the __gnu_mcount_nc > function are not generated as long calls. > > This is encountered when building an allyesconfig Linux kernel because > the Linux build system generates very large sections by

Re: [PATCH] Fix PR69771, bogus CONST_INT during shift expansion

On Fri, Feb 12, 2016 at 03:20:07PM +0100, Bernd Schmidt wrote: > >>- mode1 = GET_MODE (xop1) != VOIDmode ? GET_MODE (xop1) : mode; > >>+ mode1 = GET_MODE (xop1) != VOIDmode ? GET_MODE (xop1) : mode1; > >>if (xmode1 != VOIDmode && xmode1 != mode1) > >> { > > Here, things aren't so

Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS

Committed on gcc-5-branch as rev. 233379. 2016-02-12 0:04 GMT+01:00 Alessandro Fanfarillo : > Dear all, > > in attachment the EVENT patch for gcc-5-branch directly back-ported > from the trunk. > > Built and regtested on x86_64-pc-linux-gnu. I plan to commit this > patch

Re: [PATCH] PR driver/69779: fix bogus cleanup code used by libgccjit affecting s390x

On Fri, 2016-02-12 at 00:51 -0700, Jeff Law wrote: > On 02/11/2016 10:12 PM, David Malcolm wrote: > > In r227188 I introduced driver::finalize () which resets > > all state within gcc.c, allowing the driver code to embedded > > inside libgccjit and run repeatedly in-process. > > > > Running this

Re: [PATCH] PR driver/69779: fix bogus cleanup code used by libgccjit affecting s390x

On 02/12/2016 11:12 AM, David Malcolm wrote: The problem is that struct spec_list's "name" field is declared const: const char *name;/* name of the spec. */ and likewise for the "name" field within struct spec_list_1: const char *const name; Some are statically

Re: [PATCH] PR other/69554: avoid excessive source printing for widely-separated locations

On 02/09/2016 01:54 PM, David Malcolm wrote: gcc/ChangeLog: PR other/69554 * diagnostic-show-locus.c (struct line_span): New struct. (layout::get_first_line): Delete. (layout::get_last_line): Delete. (layout::get_num_line_spans): New member function.

Re: TR29124 C++ Special Maths - Make pull functions into global namespace.

On 12/02/16 09:52 -0800, Mike Stump wrote: On Feb 11, 2016, at 3:57 AM, Jonathan Wakely wrote: On 10/02/16 22:36 -0800, Mike Stump wrote: I’m seeing: /home/mrs/work1/gcc/libstdc++-v3/testsuite/special_functions/18_riemann_zeta/check_value.cc: In function 'void test(const

Re: Correct c-torture stkalign test

On 02/07/2016 10:55 PM, Alan Modra wrote: This test was added by git commit 7c5f55675 (svn 231569) Here's the log message from that commit: avoid alignment of static variables affecting stack's Function (or more narrow) scope static variables (as well as others not placed on the

Fix PR69648: lra removes set of PIC reg, then introduces new use

This is a PR where LRA creates a read from an uninitialized stack slot. That stack slot is supposed to hold the value of the PIC register. What seems to happen is that we have two passes making different choices: Choosing alt 0 in insn 143: (0) =x (1) 0 (2) r {sse2_pinsrw} [...]

Re: [PATCH] PR other/69554: avoid excessive source printing for widely-separated locations

On Fri, 2016-02-12 at 11:25 -0700, Jeff Law wrote: > On 02/09/2016 01:54 PM, David Malcolm wrote: > > > gcc/ChangeLog: > > PR other/69554 > > * diagnostic-show-locus.c (struct line_span): New struct. > > (layout::get_first_line): Delete. > > (layout::get_last_line): Delete. > >

Re: [PATCH] PR other/69554: avoid excessive source printing for widely-separated locations

On 02/12/2016 12:06 PM, David Malcolm wrote: On Fri, 2016-02-12 at 11:25 -0700, Jeff Law wrote: On 02/09/2016 01:54 PM, David Malcolm wrote: gcc/ChangeLog: PR other/69554 * diagnostic-show-locus.c (struct line_span): New struct. (layout::get_first_line): Delete.

Re: [PATCH] Fix PR69771, bogus CONST_INT during shift expansion

On Fri, Feb 12, 2016 at 05:34:21PM +0100, Jakub Jelinek wrote: > On Fri, Feb 12, 2016 at 03:20:07PM +0100, Bernd Schmidt wrote: > > >>- mode1 = GET_MODE (xop1) != VOIDmode ? GET_MODE (xop1) : mode; > > >>+ mode1 = GET_MODE (xop1) != VOIDmode ? GET_MODE (xop1) : mode1; > > >>if (xmode1 !=

Re: bswap PRs 69714, 67781

On 02/13/2016 03:36 AM, John David Anglin wrote: As far as the avcrc.c reduced testcase, it didn't trigger the original bug on hppa-unknown-linux-gnu. Odd, I see the same transformation in the dumps. Do you think you could investigate a bit so we get a useful testcase to add? Bernd

Re: [PATCH] Fix PR69771, bogus CONST_INT during shift expansion

On Sat, 2016-02-13 at 07:50 +, James Greenhalgh wrote: > > So do you prefer e.g. following? Bootstrapped/regtested on x86_64 > > -linux and > > i686-linux. > > > > 2016-02-12 Jakub Jelinek > > > > PR rtl-optimization/69764 > > PR rtl-optimization/69771 > >

Re: [PATCH] New flag for dumping information about constexpr function calls memoization (GCC 5.2.0)

On Fri, Jan 29, 2016 at 11:46 AM, Andres Tiraboschi wrote: > 2016-01-28 17:54 GMT-03:00 Joseph Myers : >> Any patch adding a new option needs to add documentation for it to >> invoke.texi (both substantive documentation, and

[PATCH, committed] TILE-Gx: Use CXX_FOR_BUILD to compile c++ source.

This patch uses g++ instead of gcc to compile a c++ source file. The GNU buildbot is currently failing with a c++ related link error that I have not been able to reproduce; I'm hoping using g++ will fix the issue. 2016-02-12 Walter Lee * config/tilepro/t-tilepro:

Re: TR29124 C++ Special Maths - Make pull functions into global namespace.

On Feb 12, 2016, at 1:01 PM, Jonathan Wakely wrote: > OK, thanks. t double checked the log file: -D__STDCPP_WANT_MATH_SPEC_FUNCS__ -DMAX_ITERATIONS=5 which I neglected to do the first time. With that check looking good as well, I checked it in, thanks.

Re: TR29124 C++ Special Maths - Make pull functions into global namespace.

On 12/02/16 12:39 -0800, Mike Stump wrote: On Feb 12, 2016, at 10:07 AM, Jonathan Wakely wrote: On 12/02/16 09:52 -0800, Mike Stump wrote: On Feb 11, 2016, at 3:57 AM, Jonathan Wakely wrote: On 10/02/16 22:36 -0800, Mike Stump wrote: I’m seeing:

Re: [PATCH] Fix tilegx libgcc with multilib

Hi Bernd. Thanks for looking into that. Your patch looks good and I have checked it in myself. Walter On 1/1/2016 4:31 PM, Bernd Edlinger wrote: Hi Walter, while playing with the tilegx cross compiler I noticed another defect. Currently building a tilegx cross compiler fails in libgcc

[PATCH, committed] TILE-Gx: Fix softfp build error.

This patch removes ti from softfp_int_modes for 32-bit config, to fix a compile-time assert failure. 2016-02-12 Walter Lee * config.host (tilegx*-*-linux*): remove ti from softfp_int_modes for 32-bit configs. Index: libgcc/config.host

libgo patch committed: For c-archive, install signal handler synchronously

This patch to libgo ports https://golang.org/cl/18150 from the master library to the gccgo runtime. This installs signal handlers synchronously when building a Go archive, rather than potentially racing against the main program. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.

Re: Fix PR69648: lra removes set of PIC reg, then introduces new use

On 02/12/2016 01:49 PM, Bernd Schmidt wrote: This is a PR where LRA creates a read from an uninitialized stack slot. That stack slot is supposed to hold the value of the PIC register. What seems to happen is that we have two passes making different choices: Choosing alt 0 in insn

Re: TR29124 C++ Special Maths - Make pull functions into global namespace.

On Feb 12, 2016, at 10:07 AM, Jonathan Wakely wrote: > On 12/02/16 09:52 -0800, Mike Stump wrote: >> On Feb 11, 2016, at 3:57 AM, Jonathan Wakely wrote: >>> On 10/02/16 22:36 -0800, Mike Stump wrote: I’m seeing:

Re: AW: Wonly-top-basic-asm

On 02/12/2016 05:51 AM, Bernd Schmidt wrote: On 02/12/2016 08:05 AM, David Wohlferd wrote: Actually, it was my intent that this apply to v6. It's not like there is a significant change here. We're documenting long-time behavior, and adding a (disabled) warning. The doc patch (minus

[committed] Require alias support for gcc.dg/pr67964.c

This test needs alias support. Tested on hppa2.0w-hp-hpux11.11. Committed to trunk. Dave -- John David Anglin dave.ang...@bell.net 2016-02-12 John David Anglin * gcc.dg/pr67964.c: Add dg-require-alias. Index: gcc.dg/pr67964.c

Re: bswap PRs 69714, 67781

On 2016-02-12, at 11:28 AM, Bernd Schmidt wrote: > I'm attaching a full patch. John David Anglin is currently running tests on > PA which may take a while. He's confirmed it fixes his testcase, and the > earlier 67781 testcase seems to be cured as well (only looked at generated > assembly,

Re: [PATCH] [ARC] Add single/double IEEE precission FPU support.

On 10/02/16 13:31, Claudiu Zissulescu wrote: Please find attached the amended patch for FPU instructions. Ok to apply? +(define_insn "*cmpdf_fpu" I'm wondering - could you compare with +zero using a literal (adding an alternative)? (No need to hold up the main patch, but you can consider

Re: [RFC] [PATCH] Add __array_size keyword

On Thu, Feb 11, 2016 at 10:41:02PM +, Joseph Myers wrote: > For proposed features, I find documentation and testcases of much more > value than the rest of the implementation. I can see the logic of that. This is the part that I find a little tricky, so please bear with me here. > Critical

[SH][committed] Fix PR 67636

Hi, The attached patch fixes PR 67636 in a simple way by adding yet another bit extraction pattern as mentioned in PR 64345#c3. Tested on sh-elf with make -k check RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb, -m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}" Committed to trunk as r233397.