[Bug fortran/78867] [7 Regression] GFortran function returning string ICE with -flto

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78867 --- Comment #2 from Janne Blomqvist --- (In reply to Dominique d'Humieres from comment #1) > This seems to be a regression between revisions r243624 (2016-12-13, > compiles) and r243765 (2016-12-16, ICE with -m32 or -m64). Thanks for quickly

[Bug translation/78745] Truncated messages in po file

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78745 --- Comment #3 from Frederic Marchal --- One more truncated entry in gcc/config/aarch64/aarch64.opt at line 154.

Re: [PATCH][C++] Fix PR71694, store data race with tail-padding

On December 19, 2016 11:25:49 PM GMT+01:00, Jeff Law wrote: >On 12/14/2016 03:44 AM, Richard Biener wrote: >> >> The following implements Jasons suggestion of using a langhook to >> return the size of an aggregate without tail padding that might >> be re-used when it is inherited

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516 --- Comment #16 from Peter Bergner --- (In reply to Vladimir Makarov from comment #15) > Sorry, I applied your changes manually and did a typo. The line > > SET_SRC (curr_insn_set) = new_reg; > > should be removed. > > I tested this patch

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516 --- Comment #15 from Vladimir Makarov --- (In reply to Peter Bergner from comment #13) > (In reply to Vladimir Makarov from comment #11) > > Created attachment 40372 [details] > > The proposed patch > > Agreed your additions to my change looks

[PATCH] Add testcases to test builtin-expansion of memcmp and strncmp

This patch adds tests gcc.dg/memcmp-1.c and gcc.dg/strncmp-1.c that test builtin expansion of memcmp and strncmp for short strings and also varying alignment of one arg. The strncmp test checks that things work when one of the strings crosses a 4k boundary as well. I've included interested

If you are having trouble with traffic on your site please read!

Dear Valued Member With the Holidays almost here and 2017 just around the corner, it is very important to get your online business in a position of being found on major search engines. Now a days, it's not only about keywords anymore, it's about branding your company through a very complex

[Bug c/78868] When one variadic function calls another one, the parameters are reversed, if va_arg is used directly in function call.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78868 --- Comment #4 from Andrew Pinski --- It is the call to printf and the order of evaluation of its arguments. That is take: F (g (), h ()); g or h could be called first. The same thing is true here.

[Bug c/78868] When one variadic function calls another one, the parameters are reversed, if va_arg is used directly in function call.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78868 --- Comment #3 from Vlad Krasnov --- I though that since va_arg is defined as a macro, it should be evaluated in order.

[Bug c/78868] When one variadic function calls another one, the parameters are reversed, if va_arg is used directly in function call.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78868 --- Comment #2 from Andrew Pinski --- Note C++17 does specify this more now IIRC.

[Bug c/78868] When one variadic function calls another one, the parameters are reversed, if va_arg is used directly in function call.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78868 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c/78868] New: When one variadic function calls another one, the parameters are reversed, if va_arg is used directly in function call.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78868 Bug ID: 78868 Summary: When one variadic function calls another one, the parameters are reversed, if va_arg is used directly in function call. Product: gcc

Re: [PATCH] PR 78534 Change character length from int to size_t

On 12/19/16 11:33 AM, Janne Blomqvist wrote: On Mon, Dec 19, 2016 at 6:43 PM, Bob Deen wrote: Hi all... I never saw any followup on this...? It's one thing to break the ABI between the compiler and the gfortran library; those can generally be expected to be in sync.

[Bug fortran/78866] ICE in gimplify_adjust_omp_clauses_1, at gimplify.c:8721

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78866 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug fortran/78865] ICE in create_tmp_var, at gimple-expr.c:473

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78865 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug fortran/78867] [7 Regression] GFortran function returning string ICE with -flto

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78867 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4

[Bug target/78683] [ppc] __builtin_ctzl code gen can be improved for -mcpu=power8 and earlier

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78683 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

Re: Reorganise machmode.h headers

On 11/16/2016 09:32 AM, Richard Sandiford wrote: Later patches will make machmode.h rely on wide-int.h and the new poly-int.h, so it needs to appear later in the coretypes.h include list. Previously machmode.h included insn-modes.h, which as well as the main mode enum contains configuration

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516 --- Comment #14 from Peter Bergner --- (In reply to Joseph S. Myers from comment #12) > Created attachment 40373 [details] > fnmatch.i preprocessed source > > With that new LRA patch (plus the previous gcc-pr78516.v2.diff) I get an ICE >

Re: Problem with Factory Generated code g++ 4.x, 5.x, 6.x

On 12/18/2016 12:15 PM, Eduardo Yÿffe1nez via gcc-bugs wrote: >I wish to report a problem with g++ 4.x, g++ 5.x, g++ 6.x. I'm trying >to implement a very classic Factory Method Pattern in C++, I can do it >very easily in MS-Visual C++, but in Linux with g++ the code compiles >but I get

Re: [PR tree-optimization/71691] Fix unswitching in presence of maybe-undef SSA_NAMEs (take 2)

On 12/16/2016 07:41 AM, Aldy Hernandez wrote: BTW, I don't understand why we don't have auto_bitmap's, as we already have auto_sbitmap's. I've implemented the former based on auto_sbitmap's code we already have. Trevor poked at it a bit. bitmaps are a bit more complex than sbitmaps in terms

Re: [PATCH] Fix bug in MEM parsing in patches 8a/8b

On Mon, 2016-12-19 at 15:10 -0700, Jeff Law wrote: > On 12/08/2016 01:39 PM, David Malcolm wrote: > > Testing the patch kit on i686 showed numerous failures of this > > assertion in set_mem_attributes_minus_bitpos in emit-rtl.c: > > > > 1821gcc_assert (!defattrs->offset_known_p); > > >

Re: [fortran, patch] Remove unused elements in array argument to set_options

On Mon, Dec 19, 2016 at 11:29:45PM +0100, FX wrote: > > Thinking out loud here. I wonder, however, if we want > > to future proof the library against changes to the > > options passed by having a few spare unused entried > > available. This of course only helps if a new option > > needs to be

Re: [PATCH] fix integer overflow bugs in gimple-ssa-sprintf.c (PR 78608)

On 12/14/2016 09:41 AM, Martin Sebor wrote: - if (i < 0) + if (HOST_WIDE_INT_MIN == i) nit. I think most folks would probably prefer this as if (i == HOST_WIDE_INT_MIN). HOST_WIDE_INT_MIN is a constant and when we can write an expression in either order variable OP const is the

Re: [fortran, patch] Remove unused elements in array argument to set_options

> Thinking out loud here. I wonder, however, if we want > to future proof the library against changes to the > options passed by having a few spare unused entried > available. This of course only helps if a new option > needs to be added. It does nothing for removal. That’s actually the way

Re: [PATCH][C++] Fix PR71694, store data race with tail-padding

On 12/14/2016 03:44 AM, Richard Biener wrote: The following implements Jasons suggestion of using a langhook to return the size of an aggregate without tail padding that might be re-used when it is inherited from. Using this langhook we can fix the size of the representative for the bitfield

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516 --- Comment #13 from Peter Bergner --- (In reply to Vladimir Makarov from comment #11) > Created attachment 40372 [details] > The proposed patch Agreed your additions to my change looks good. However, I'm not so sure about this last hunk: -

Re: [PATCH] correct %g handling with unknown arguments in -fprintf-return-value (PR 78696)

On 12/12/2016 05:06 PM, Martin Sebor wrote: +/* The lower bound when precision isn't specified is 8 bytes + ("1.23456" since precision is taken to be 6). When precision + is zero, the lower bound is 1 byte (e.g., "1"). Otherwise, + when precision is greater than zero,

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516 --- Comment #12 from Joseph S. Myers --- Created attachment 40373 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40373=edit fnmatch.i preprocessed source With that new LRA patch (plus the previous gcc-pr78516.v2.diff) I get an ICE

RE: [PATCH, testsuite] MIPS: Relax instruction order check in msa-builtins.c.

> -Original Message- > From: Toma Tabacu [mailto:toma.tab...@imgtec.com] > Sent: Thursday, December 15, 2016 9:51 AM > To: gcc-patches@gcc.gnu.org > Cc: Matthew Fortune ; Moore, > Catherine > Subject: [PATCH, testsuite] MIPS: Relax

Re: [fortran, patch] Remove unused elements in array argument to set_options

On Mon, Dec 19, 2016 at 10:47:09PM +0100, FX wrote: > For ABI compatibility, we kept some unused elements in the array argument to > _gfortran_set_options (options that we have removed). With the current ABI > breakage, we might as well remove those. > > Bootstrapped and regtested on

Re: [PATCH] Fix bug in MEM parsing in patches 8a/8b

On 12/08/2016 01:39 PM, David Malcolm wrote: Testing the patch kit on i686 showed numerous failures of this assertion in set_mem_attributes_minus_bitpos in emit-rtl.c: 1821gcc_assert (!defattrs->offset_known_p); when expanding "main" in the rtl.exp test files, after parsing an

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On 12/19/2016 01:09 PM, Martin Sebor wrote: By moving the warning earlier, we'll still warn for the most cases, but won't warn in the more convoluted cases. We can perhaps work on it further in GCC 8. If we keep it as is, I think most users will just -Wno-nonnull as soon as they run into some

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516 --- Comment #11 from Vladimir Makarov --- Created attachment 40372 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40372=edit The proposed patch

[Bug fortran/78867] New: GFortran function returning string ICE with -flto

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78867 Bug ID: 78867 Summary: GFortran function returning string ICE with -flto Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3

[fortran, patch] Remove unused elements in array argument to set_options

For ABI compatibility, we kept some unused elements in the array argument to _gfortran_set_options (options that we have removed). With the current ABI breakage, we might as well remove those. Bootstrapped and regtested on x86_64-apple-darwin16.3.0 OK to commit? FX set_options.ChangeLog

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516 --- Comment #10 from Vladimir Makarov --- (In reply to Peter Bergner from comment #8) > where "src" is the subreg:SI ..., so the new_reg mode will be SImode and we > then replace the whole SET_SRC (curr_insn_set) which is the subreg:SI >

Re: [PATCH] [PR rtl-optimization/65618] Fix MIPS ADA bootstrap failure

On 12/19/2016 08:44 AM, James Cowgill wrote: Hi, This patch fixes PR 65618 where ADA cannot be bootstrapped natively on mips due to a bootstrap comparison failure. The PR is currently in the target component, but should be in the rtl-optimization component. The underlying bug is in

[Bug fortran/78505] [F08] Coarray source allocation not synchronizing on oversubscribed cores

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78505 --- Comment #8 from Damian Rouson --- Thanks.

[Bug middle-end/78047] [5 Regression] Chromium apparently gets miscompiled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78047 Markus Trippelsdorf changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED

[Bug middle-end/78047] [5 Regression] Chromium apparently gets miscompiled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78047 Markus Trippelsdorf changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug middle-end/78047] [5 Regression] Chromium apparently gets miscompiled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78047 Markus Trippelsdorf changed: What|Removed |Added CC||Casey at Carter dot net ---

[Bug c++/78841] [6 regression] optimizer bug (silent bad codegen)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78841 Markus Trippelsdorf changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #6 from

[Bug c++/78841] [6 regression] optimizer bug (silent bad codegen)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78841 --- Comment #5 from Casey Carter --- I have verified that gcc-6-branch compiles the repro correctly, so yes, this is a dup of PR78047.

[Bug c++/78841] [6 regression] optimizer bug (silent bad codegen)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78841 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4

[Bug fortran/78505] [F08] Coarray source allocation not synchronizing on oversubscribed cores

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78505 --- Comment #7 from Andre Vehreschild --- As you can see from the commit message in comment #3 it hit trunk on 9th of Dezember. Am 19. Dezember 2016 21:03:38 MEZ, schrieb damian at sourceryinstitute dot org :

Re: [PATCH] detect null sprintf pointers (PR 78519)

On Mon, Dec 19, 2016 at 01:24:34PM -0700, Jeff Law wrote: > > PR middle-end/78519 - missing warning for sprintf %s with null pointer > > > > gcc/ChangeLog: > > > > PR middle-end/78519 > > * gimple-ssa-sprintf.c (format_string): Handle null pointers. > > (format_directive): Diagnose

[committed] print_rtx_function: update example in comment

The patch updates the example dump in the comment for print_rtx_function to reflect various changes: - r241593: addition of insn UIDs - r241908: removal of trailing "(nil)" and other default values - r242023: addition of "param" directives - r243798: change of format of regnos in non-virtual

Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers in GIMPLE.

On 12/15/2016 03:14 AM, Tamar Christina wrote: On a high level, presumably there's no real value in keeping the old code to "fold" fpclassify. By exposing those operations as integer logicals for the fast path, if the FP value becomes a constant during the optimization pipeline we'll see the

[PATCH, i386] Add *popcounthi2_1 insn and splitter

Hello! This patch just adds missing popcounthi2 insn and splitter to enable POPCNTW generation from _builtin_popcount builtin with zero-extended unsigned short argument. 2016-12-19 Uros Bizjak * config/i386/i386.md (*popcounthi2_1): New insn_and_split pattern.

[PATCH] Add "__RTL" to cc1 (v7)

This is the final part of the RTL "frontend" patch kit, implemented as a special case for functions marked with __RTL within the C frontend. Successfully bootstrapped on x86_64-pc-linux-gnu on top of the rest of the RTL frontend patch kit. OK for trunk? Changed in v7: - remove i?86-*-* from

[Bug c++/78842] "error: declaration of 'bool icase' shadows a parameter" should be warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78842 --- Comment #3 from Jakub Jelinek --- (In reply to Nathan Sidwell from comment #2) > Created attachment 40370 [details] > trimmed testcase Isn't this from PR78840 instead?

Re: [PATCH] detect null sprintf pointers (PR 78519)

On 12/14/2016 09:21 PM, Martin Sebor wrote: I suppose setting a range seemed better than giving up. Then again, since with this patch GCC will warn on null %s pointers there may not be much point in trying to see if there's also some other problem after that, except perhaps in code that

Re: Why are GCC Internals not Specification Driven ?

Seima Rao writes: > Has gcc become proprietory/commercial ? By definition: no, yes. It's been this way since the beginning, and hasn't changed in decades. > Or has it become illegal to publish specification models > of gcc internals ? Does this make the

Re: [PATCH] Optimiza aggregate a = b = c = {} (PR c/78408, take 2)

On 12/16/2016 05:50 AM, Richard Biener wrote: + gimple *defstmt = SSA_NAME_DEF_STMT (vuse); + tree src2 = NULL_TREE, len2 = NULL_TREE; + HOST_WIDE_INT offset, offset2; + tree val = integer_zero_node; + if (gimple_store_p (defstmt) + && gimple_assign_single_p (defstmt) + &&

[doc, committed] CPP manual cleanup, part 1

I've checked in this patch to do some initial cleanup of bit-rotten content in the CPP manual. I've rewritten some passages that made it sound like C99 support is a brand-new thing, and removed text that describes how the preprocessor used to work in ancient versions of GCC. This is all

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

By moving the warning earlier, we'll still warn for the most cases, but won't warn in the more convoluted cases. We can perhaps work on it further in GCC 8. If we keep it as is, I think most users will just -Wno-nonnull as soon as they run into some warning that will be hard to figure out what

[Bug fortran/78505] [F08] Coarray source allocation not synchronizing on oversubscribed cores

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78505 --- Comment #6 from Damian Rouson --- Please let me know which day this hit (or will hit) the trunk. I'm currently using a build dated 20161215.

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On 12/16/2016 10:10 AM, Martin Sebor wrote: On 12/16/2016 09:46 AM, Jakub Jelinek wrote: On Fri, Dec 16, 2016 at 09:36:25AM -0700, Martin Sebor wrote: It does for me with an allmodconf. At -O2 I get three warnings, and at -O3 I get two additional warnings. Now these additional ones happen way

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On Mon, Dec 19, 2016 at 12:50:00PM -0700, Jeff Law wrote: > > Unrelated to where the warning is issued, it might be a good idea to use > > %K to emit it with inlining stack, otherwise figuring out why it warns > > will be harder than needed. > I would think that would apply to any warning

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On 12/19/2016 12:12 PM, Jakub Jelinek wrote: On Mon, Dec 19, 2016 at 07:58:54PM +0100, Jakub Jelinek wrote: On Mon, Dec 19, 2016 at 11:54:06AM -0700, Jeff Law wrote: I don't claim it can't be improved but it seems pretty good as it is already. Among the 6 instances it's found in GCC three

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On 12/19/2016 11:56 AM, Jakub Jelinek wrote: On Mon, Dec 19, 2016 at 11:46:24AM -0700, Jeff Law wrote: But I don't see that as inherently blocking this patch. It's pointing out a bad API interface. It's no different than when I added teh NULL pointer dereference warnings a while ago -- we had

Re: Do we really need a CPP manual?

On 12/19/2016 07:17 PM, Joseph Myers wrote: When BSI consulted on the ISO strategic plan consultation for 2016-2020 my response said that all standards should be freely licensed (I said 'I would like to see these points reflected in BSI's response to ISO. ... Thus: the goal for ISO should be to

[Bug fortran/78864] ICE in dtio_procs_present, at fortran/resolve.c:13819

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78864 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|

[Bug fortran/78659] [F03] Spurious "requires DTIO" reported against namelist statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78659 Jerry DeLisle changed: What|Removed |Added CC||gerhard.steinmetz.fortran@t

Re: [PATCH] PR 78534 Change character length from int to size_t

On Mon, Dec 19, 2016 at 6:43 PM, Bob Deen wrote: > Hi all... > > I never saw any followup on this...? > > It's one thing to break the ABI between the compiler and the gfortran > library; those can generally be expected to be in sync. It's another to > break the ABI between

[Bug c++/78841] [6 regression] optimizer bug (silent bad codegen)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78841 Markus Trippelsdorf changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|---

[Bug c++/78841] [6 regression] optimizer bug (silent bad codegen)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78841 --- Comment #2 from Casey Carter --- Created attachment 40371 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40371=edit compressed preprocessed repro

[Bug fortran/78659] [F03] Spurious "requires DTIO" reported against namelist statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78659 --- Comment #12 from Jerry DeLisle --- (In reply to janus from comment #8) The case that ICEs needs to have an error check in io.c (gfc_resolve_dt). I have found the location and now need to build the error check.

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On Mon, Dec 19, 2016 at 07:58:54PM +0100, Jakub Jelinek wrote: > On Mon, Dec 19, 2016 at 11:54:06AM -0700, Jeff Law wrote: > > > > I don't claim it can't be improved but it seems pretty good as > > > > it is already. Among the 6 instances it's found in GCC three > > > > look like real bugs. > > >

[Bug fortran/78662] [F03] Incorrect parsing of quotes in the char-literal-constant of the DT data descriptor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78662 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug middle-end/78622] [7 Regression] -Wformat-length/-fprintf-return-value incorrect with overflow/wrapping

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78622 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org ---

Re: Question about ASMCONS

On 19/12/2016 18:06, Segher Boessenkool wrote: Hi Claudiu, On Mon, Dec 19, 2016 at 12:28:54PM +, Claudiu Zissulescu wrote: I have the following rtl before asmcons pass: (insn 8 13 9 2 (set (reg:SI 157 [ list ]) (asm_operands:SI ("") ("=g") 0 [ (const:SI (unspec:SI

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On Mon, Dec 19, 2016 at 11:54:06AM -0700, Jeff Law wrote: > > > I don't claim it can't be improved but it seems pretty good as > > > it is already. Among the 6 instances it's found in GCC three > > > look like real bugs. > > > > None look like real bugs to me. > But is the warning rate so high

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On Mon, Dec 19, 2016 at 11:46:24AM -0700, Jeff Law wrote: > But I don't see that as inherently blocking this patch. It's pointing out a > bad API interface. It's no different than when I added teh NULL pointer > dereference warnings a while ago -- we had the exact same kinds of problems. > >

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On 12/16/2016 09:46 AM, Jakub Jelinek wrote: On Fri, Dec 16, 2016 at 09:36:25AM -0700, Martin Sebor wrote: It does for me with an allmodconf. At -O2 I get three warnings, and at -O3 I get two additional warnings. Now these additional ones happen way too deep into the pipeline to be reliable.

[Bug middle-end/71473] [5/6/7 Regression] cilkplus sum reducer ICE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71473 Pablo Halpern changed: What|Removed |Added CC||bugzilla@halpernwightsoftwa

Re: [gimplefe] reject invalid pass name in startwith

The message passed to error_at should not end in \n; the diagnostics machinery deals with inserting the newline. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On 12/19/2016 11:30 AM, Jakub Jelinek wrote: On Mon, Dec 19, 2016 at 10:52:13AM -0700, Jeff Law wrote: No, it highlights that the warning is done in a wrong place where it suffers from too many false positives. I don't inherently see this as generating "too many false positives". And as Martin

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On 12/19/2016 11:00 AM, Martin Sebor wrote: On 12/19/2016 10:31 AM, Jeff Law wrote: On 12/17/2016 02:55 PM, Martin Sebor wrote: On 12/17/2016 01:01 PM, Markus Trippelsdorf wrote: I agree that these warnings should probably not be issued, though it's interesting to see where they come from.

[Bug c++/78842] "error: declaration of 'bool icase' shadows a parameter" should be warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78842 Nathan Sidwell changed: What|Removed |Added CC||nathan at gcc dot gnu.org --- Comment

[Bug c++/78840] [5/6/7 Regression] ICE with const variables in templates implicitly captured by nested lambda expressions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78840 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED CC|

[Bug fortran/78866] ICE in gimplify_adjust_omp_clauses_1, at gimplify.c:8721

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78866 --- Comment #1 from Gerhard Steinmetz --- Older versions down to at least 5.4.1 give : $ gfortran-7-20161023 -fopenmp -c z1.f90 z1.f90:4:0: !$omp target internal compiler error: Segmentation fault

[Bug fortran/78866] New: ICE in gimplify_adjust_omp_clauses_1, at gimplify.c:8721

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78866 Bug ID: 78866 Summary: ICE in gimplify_adjust_omp_clauses_1, at gimplify.c:8721 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On Mon, Dec 19, 2016 at 10:52:13AM -0700, Jeff Law wrote: > > No, it highlights that the warning is done in a wrong place where it suffers > > from too many false positives. > I don't inherently see this as generating "too many false positives". And as > Martin says, the warning works with

[Bug fortran/78865] New: ICE in create_tmp_var, at gimple-expr.c:473

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78865 Bug ID: 78865 Summary: ICE in create_tmp_var, at gimple-expr.c:473 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug fortran/78864] ICE in dtio_procs_present, at fortran/resolve.c:13819

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78864 --- Comment #1 from Gerhard Steinmetz --- Older versions give : $ gfortran-7-20160828 z1.f90 z1.f90:5:16: namelist /nml/ x 1 Error: NAMELIST object 'x' in namelist 'nml' at (1) is

[Bug fortran/78864] New: ICE in dtio_procs_present, at fortran/resolve.c:13819

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78864 Bug ID: 78864 Summary: ICE in dtio_procs_present, at fortran/resolve.c:13819 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug rtl-optimization/78751] [7 Regression] ICE in extract_insn, at recog.c:2311 (error: unrecognizable insn) w/ -Os -misel

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78751 --- Comment #2 from Segher Boessenkool --- In this testcase ifcvt happens upon a branch like: (jump_insn 28 27 65 2 (set (pc) (if_then_else (eq (reg:CCEQ 183) (const_int 0 [0])) (label_ref:SI 65)

Re: [PATCH] PR 78534 Change character length from int to size_t

On Mon, Dec 19, 2016 at 08:43:01AM -0800, Bob Deen wrote: > > It's one thing to break the ABI between the compiler and the gfortran > library; those can generally be expected to be in sync. It's another to > break the ABI between two *languages*, when there might be no such > expectation

Re: Do we really need a CPP manual?

On Mon, 19 Dec 2016, Florian Weimer wrote: > On 12/16/2016 07:06 PM, Jeff Law wrote: > > > That's likely the manual RMS kept asking folks (semi-privately) to > > review. My response was consistently that such review should happen > > publicly, which RMS opposed for reasons I don't recall. > >

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On Mon, Dec 19, 2016 at 10:52:13AM -0700, Jeff Law wrote: > > > > None look like real bugs to me. > > > > > > They do to me. There are calls in gengtype.c to a function decorated > > > with attribute nonnull (lbasename) that pass to it a pointer that's > > > potentially null. For example below.

[Bug middle-end/71473] [5/6/7 Regression] cilkplus sum reducer ICE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71473 --- Comment #6 from tprince at computer dot org --- __sec_reduce_{min,max}_ind in Intel cilk(tm) plus don't give good performance, so one may suspect they are using size_t.(In reply to Jakub Jelinek from comment #5) > While this started with my

[PATCH] Add support for Fuchsia (OS)

Ping? On 12/12/16 1:31 PM, Josh Conner wrote: On 12/10/16 3:26 AM, Richard Earnshaw wrote: On 08/12/16 22:55, Josh Conner wrote: +arm*-*-fuchsia*) + tm_file="${tm_file} fuchsia.h arm/fuchsia-elf.h glibc-stdint.h" + tmake_file="${tmake_file} arm/t-bpabi" + ;; This will

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On 12/19/2016 10:31 AM, Jeff Law wrote: On 12/17/2016 02:55 PM, Martin Sebor wrote: On 12/17/2016 01:01 PM, Markus Trippelsdorf wrote: I agree that these warnings should probably not be issued, though it's interesting to see where they come from. The calls are in the code emitted by GCC, are

libgo patch committed: Copy/rewrite cgo support code from Go 1.7 runtime

This patch copies the cgo support code from the Go 1.7 runtime to libgo. The cgo support in gccgo is rather different, so all the code in cgo_gccgo.go is gccgo-specific. The rest of the code is similar but slightly different. This drops _cgo_allocate, which was removed from the gc toolchain

[Patch] Turn -fexcess-precision=fast on when in -ffast-math

> On Thu, Dec 8, 2016 at 10:44 PM, Uros Bizjak wrote: > > Hello! > > > > Attached patch fixes fall-out from excess-precision improvements > > patch. As shown in the PR, the code throughout the compiler assumes > > FLAG_PRECISION_FAST when flag_unsafe_math_optimizations flag is

Re: [PATCH] libstdc++: Allow using without lock free atomic int

On 16/12/16 17:52 +, Jonathan Wakely wrote: On 09/11/16 23:26 +0200, Pauli wrote: Compiling programs using std::future for old arm processors fails. The problem is caused by preprocessor check for atomic lock free int. Future can be changed to work correctly without lock free atomics with

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On 12/16/2016 10:27 AM, Jakub Jelinek wrote: On Fri, Dec 16, 2016 at 10:10:00AM -0700, Martin Sebor wrote: No. The first call to sm_read_sector just doesn't exit. So it is warning about dead code. If the code is dead then GCC should eliminate it. With it eliminated There is (especially

Re: [PATCH, rs6000] Fold vector multiply built-ins in GIMPLE

Hi Will, On Mon, Dec 19, 2016 at 11:01:19AM -0600, Will Schmidt wrote: > This patch implements folding of the vector Multiply built-ins. > > As part of this patch, I have also marked variables in an existing > testcase (mult-even-odd-be-order.c) as volatile, to prevent their being > optimized

  1   2   3   >