[Bug c++/78843] New: error: 'functionname' was not declared in this scope

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78843 Bug ID: 78843 Summary: error: 'functionname' was not declared in this scope Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78842 Bug ID: 78842 Summary: "error: declaration of 'bool icase' shadows a parameter" should be warning Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity:

[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|UNCONFIRMED |WAITING Last reconfirmed|

[Bug c++/78826] jump bypasses non-POD

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78826 --- Comment #3 from Krzysztof Laskowski --- (In reply to Jonathan Wakely from comment #2) > I assume GCC 4.5 stopped diagnosing it due to the revised specification > which only cares about trivial constructor or trivial destructor, not >

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78841 Bug ID: 78841 Summary: [6 regression] optimizer bug (silent bad codegen) Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug c++/78840] New: ICE with const variables in templates implicitly captured by nested lambda expressions

20161216. Earlier versions from 4.5.4 to 4.9.4, and clang successfully compiles the code. http://melpon.org/wandbox/permlink/hJM9b4zWQzTJeBLp int gvar; template void tfunc2(int, F) {} template void tfunc() { // ICE is caused when, in function templates, const int a = gvar; // a const variable

[Bug c++/78826] jump bypasses non-POD

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78826 --- Comment #2 from Jonathan Wakely --- GCC 4.4.7 gives an error: pod.cc: In function ‘void should_not_compile()’: pod.cc:6: error: jump to label ‘label’ pod.cc:4: error: from here pod.cc:5: error: enters scope of non-POD ‘non_pod_in_cpp03

[Bug other/78839] DWARF output different between GCC 5 and 6

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839 --- Comment #6 from Tom O'Connor --- (In reply to Andrew Pinski from comment #5) > (In reply to Tom O'Connor from comment #4) > > Bitfields seemed to work fine in all GCC prior to 6, FWIW. The same > > attached source code when built with other

[Bug other/78839] DWARF output different between GCC 5 and 6

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839 --- Comment #5 from Andrew Pinski --- (In reply to Tom O'Connor from comment #4) > Bitfields seemed to work fine in all GCC prior to 6, FWIW. The same > attached source code when built with other GCCs prior to 6 generates >

[Bug other/78839] DWARF output different between GCC 5 and 6

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839 --- Comment #4 from Tom O'Connor --- Bitfields seemed to work fine in all GCC prior to 6, FWIW. The same attached source code when built with other GCCs prior to 6 generates DW_AT_data_member_location = 0 for all the fields as expected. Only 6

[Bug other/78839] DWARF output different between GCC 5 and 6

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839 --- Comment #3 from Andrew Pinski --- IIRC bitfield are broken for dwarf2/3 and there is another mechanism for them for dwarf5.

RE: Re: DWARF output different between GCC 5 and 6

Opened as bug 78839 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839 From: Jakub Jelinek [ja...@redhat.com] Sent: Friday, December 16, 2016 6:03 PM To: Tom O'Connor Cc: gcc@gcc.gnu.org Subject: EXTERNAL: Re: DWARF output different between GCC 5 and 6 On

[Bug other/78839] DWARF output different between GCC 5 and 6

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839 --- Comment #2 from Tom O'Connor --- Created attachment 40355 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40355=edit debuginfo from a GCC 6.1.0 build of s.c

[Bug other/78839] DWARF output different between GCC 5 and 6

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839 --- Comment #1 from Tom O'Connor --- Created attachment 40354 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40354=edit debuginfo from a GCC 5.4.0 build of s.c

[Bug other/78839] New: DWARF output different between GCC 5 and 6

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839 Bug ID: 78839 Summary: DWARF output different between GCC 5 and 6 Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other

[PATCH v2,rs6000] PR78056: Finish fixing build failure on Power7

This patch adds warning messages and test cases to an initial patch already submitted and committed to the trunk on October 26, 2016. The earlier patch disables initialization of built-in functions which depend on assembler capabilities that are not supported by the associated tool chain. The

[Bug target/71216] [4.9/5/6/7 Regression] Incorrect PPC assembly due to inserted .machine pseudo-op

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71216 --- Comment #8 from Segher Boessenkool --- Hi Rin, > However, I have a question on this fix. How about the case where > "-Wa,-mXXX" option is given without "-mcpu=YYY" option specified? That might or might not work; the user had better know

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516 --- Comment #9 from joseph at codesourcery dot com --- That LRA patch (on top of the previous patch) allows the glibc build to complete. Now running gcc/g++/libstdc++ testsuites (I haven't run them with an unmodified copy of the same GCC

Re: [PATCH] builtin expansion of strncmp for rs6000

Hi Aaron, On Thu, Dec 15, 2016 at 10:31:05AM -0600, Aaron Sawdey wrote: > This patch adds a cmpstrnsi pattern for rs6000 target to provide > builtin expansion of strncmp(). Perf tests on a power8 system show that > it is 3-10x faster than the glibc strncmp on RHEL7 for lengths under 64 > bytes. >

[Bug fortran/56691] [OOP] Allocatable array: wrong offset when passing to CLASS dummy

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56691 janus at gcc dot gnu.org changed: What|Removed |Added Known to work|6.2.0, 7.0 | Target Milestone|6.2

Re: DWARF output different between GCC 5 and 6

On Fri, Dec 16, 2016 at 10:30:09PM +, Tom O'Connor wrote: > I've observed a difference in DWARF output for the same input source code > between GCC 5 and GCC 6, specifically in the DW_AT_data_member_location > values for bitfield members of structs. For example, This changed with

[Bug target/78838] New: msp430 option -mcode-region=either, -ffunction-sections, and interrupt function attributes cause incorrect section to be created

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78838 Bug ID: 78838 Summary: msp430 option -mcode-region=either, -ffunction-sections, and interrupt function attributes cause incorrect section to be created Product: gcc

[Bug driver/70936] Hard-coded C++ header paths and relocation problem on Windows

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70936 --- Comment #11 from Rolf Eike Beer --- I configured with: ../gcc-host/configure --target=i686-unknown-linux-gnu --host=x86_64-pc-linux- gnu --build=x86_64-pc-linux-gnu --program-prefix=i686-unknown-linux-gnu- --

Re: [LRA] Fix ICE for paradoxical subregs on strict-alignment platforms

On 12/13/2016 05:05 PM, Eric Botcazou wrote: Hi, the Ada runtime library doesn't build on SPARC 32-bit with LRA because of an ICE on a couple of files: eric@polaris:~/build/gcc/sparc-sun-solaris2.10> gcc/gnat1 -I gcc/ada/rts - quiet -dumpbase g-debpoo.adb -auxbase g-debpoo -O2 -gnatpg -fPIC

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516 Peter Bergner changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment

DWARF output different between GCC 5 and 6

Hello, I've observed a difference in DWARF output for the same input source code between GCC 5 and GCC 6, specifically in the DW_AT_data_member_location values for bitfield members of structs. For example, s.c: struct s { unsigned int shutdown:2, no_check_tx:1, no_check_rx:1,

[Bug fortran/56691] [OOP] Allocatable array: wrong offset when passing to CLASS dummy

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56691 Dominique d'Humieres changed: What|Removed |Added Status|RESOLVED|NEW Resolution|FIXED

[Bug fortran/56691] [OOP] Allocatable array: wrong offset when passing to CLASS dummy

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56691 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work|

Go patch committed: pass function to all backend methods that create statements

This patch by Than McIntosh to the Go frontend changes the backend interface to pass the function to all the methods that create statements. Having the function available simplifies things if a temporary variable has to be created during the construction of a statement. This also includes a

[Bug fortran/78661] [F03] Namelist output missing object designator under DTIO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661 --- Comment #5 from janus at gcc dot gnu.org --- Btw, this variant is wrongly rejected: MODULE m IMPLICIT NONE TYPE :: t CHARACTER :: c CONTAINS PROCEDURE :: write_formatted GENERIC :: WRITE(FORMATTED) => write_formatted END

[Bug fortran/78661] [F03] Namelist output missing object designator under DTIO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661 --- Comment #4 from janus at gcc dot gnu.org --- I think this should fix it: Index: libgfortran/io/write.c === --- libgfortran/io/write.c (revision 243729) +++

[Bug rtl-optimization/78580] [6/7 Regression] Segfault in gcc with multilib (-m32) and -ffixed-*

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78580 --- Comment #3 from Vladimir Makarov --- (In reply to Jakub Jelinek from comment #2) > > So, is the bug that i?86 needs Q_REGS to be an allocno class always (shall > ix86_additional_allocno_class_p return true also for Q_REGS? Just for -m32 >

[Bug middle-end/78837] New: missing -Walloca-larger-than on a call in a ternary expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78837 Bug ID: 78837 Summary: missing -Walloca-larger-than on a call in a ternary expression Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal

[Bug fortran/78661] [F03] Namelist output missing object designator under DTIO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661 --- Comment #3 from janus at gcc dot gnu.org --- Reduced test case: MODULE m IMPLICIT NONE TYPE :: t CHARACTER :: c CONTAINS PROCEDURE :: write_formatted GENERIC :: WRITE(FORMATTED) => write_formatted END TYPE CONTAINS

[Bug fortran/56691] [OOP] Allocatable array: wrong offset when passing to CLASS dummy

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56691 physiker at toast2 dot net changed: What|Removed |Added CC||physiker at toast2 dot net

[Bug ada/62122] GNAT RM: flaw in example of @node Attribute Unrestricted_Access

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62122 --- Comment #2 from Georg --- Created attachment 40352 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40352=edit changes to example in GNAT RM section on Unrestricted_Access Since variable Global needs initialization, I have added an

[Bug c++/71972] [6 Regression] ICE with "-std=c++14" on x86_64-linux-gnu (internal compiler error: Segmentation fault, cxx_eval_store_expression)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71972 Jakub Jelinek changed: What|Removed |Added CC||gcc at tnix dot eu --- Comment #8 from

[Bug c++/71229] internal compiler error: Segmentation fault, when copying an array in a constexpr function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71229 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug c++/71226] [C++14] ICE in fold_binary_loc, at fold-const.c:9252, from constexpr function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71226 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug c++/71972] [6 Regression] ICE with "-std=c++14" on x86_64-linux-gnu (internal compiler error: Segmentation fault, cxx_eval_store_expression)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71972 Jakub Jelinek changed: What|Removed |Added CC||gccbug at kundor dot org --- Comment #7

[Bug preprocessor/78836] New: ICE in get_source_location_for_substring, at input.c:1461

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78836 Bug ID: 78836 Summary: ICE in get_source_location_for_substring, at input.c:1461 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal

[PATCH] Fix -fcompare-debug sanopt bug (PR sanitizer/78832)

Hi! The following testcase fails with -fcompare-debug, because we have a bb containing 2 ASAN_MARK (POISON, ...) calls immediately after each other, followed with -g only by debug stmts till end of basic block. sanitize_asan_mark_poison walks stmts in a bb backwards and assumes (incorrectly) that

[Bug c++/71226] [C++14] ICE in fold_binary_loc, at fold-const.c:9252, from constexpr function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71226 --- Comment #4 from Nick Matteo --- Appears to be fixed in GCC 6.2.0.

[PATCH] varasm: Propagate litpool decl alignment to generated RTX.

When pushing a value into the literal pool the resulting decl might get a higher alignment than the original expression depending on how a target defines CONSTANT_ALIGNMENT. Generating an RTX for the constant pool access we currently use the alignment from the original expression. Changed with

[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 --- Comment #5 from Jerry DeLisle --- Author: jvdelisle Date: Fri Dec 16 20:27:51 2016 New Revision: 243765 URL: https://gcc.gnu.org/viewcvs?rev=243765=gcc=rev Log: 2016-12-16 Jerry DeLisle PR fortran/78622

Re: Fix for libstdc++-v3's error_constants.h for MinGW-W64

On 16/12/16 16:28 +0300, niXman wrote: Jonathan Wakely 2016-12-16 16:04: I don't think this is suitable for the branches, but could be applied to trunk (as the patch was posted during stage 1, but I missed it). Ok. Does this require a particular version of MinGW-w64? Yes, at the moment

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

On Fri, Dec 16, 2016 at 01:01:13PM -0700, Jeff Law wrote: > > Thanks. Reduced to something like: > > int > > foo (const char *name) > > { > > if (name) > > return 6; > > return __builtin_strlen (name); > > } > > This is warned about both with Martin's late warning and my after ccp2 > >

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

On 12/16/2016 11:40 AM, Jakub Jelinek wrote: On Fri, Dec 16, 2016 at 07:29:13PM +0100, Markus Trippelsdorf wrote: So, to be fair a gave Jakub's patch a try and it has exactly the same issues for the Linux kernel: sometimes the warning only triggers with -O3, e.g.: % cat sm_ftl.i int a; void

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

On 12/16/2016 12:08 PM, Jakub Jelinek wrote: On Fri, Dec 16, 2016 at 07:00:06PM +, Joseph Myers wrote: On Fri, 16 Dec 2016, Martin Sebor 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.

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

On 12/16/2016 12:08 PM, Jakub Jelinek wrote: On Fri, Dec 16, 2016 at 07:00:06PM +, Joseph Myers wrote: On Fri, 16 Dec 2016, Martin Sebor 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.

Re: [patch,fortran] PR78622 [F03] Incorrect parsing of quotes in the char-literal-constant of the DT data descriptor

On Fri, Dec 16, 2016 at 4:16 AM, Jerry DeLisle wrote: > Hi all, > > The attached patch regression tested on x86-64-linux. > > This adds a static function to allocate and extract the DT format string > that may contain doubled quotes. > > OK for trunk, test case also

[PATCH 1/2] print-rtl.c: use '<' and '>' rather than % for pseudos in compact mode

On Fri, 2016-12-16 at 10:32 -0500, David Malcolm wrote: > On Fri, 2016-12-16 at 14:28 +0100, Bernd Schmidt wrote: > > On 12/14/2016 05:57 PM, David Malcolm wrote: > > > Any preferences? (or other syntax ideas?). My preference is one > > > of > > > the > > > currently-unused sigils e.g. "@3", or

[PATCH 2/2] Changes to patch 8a to use <3> syntax

For reference, here are the changes to patch 8a to update it to the new syntax. I'm assuming that this (and the changes to the various dumpfiles in patches 8b-8d) count as "obvious". gcc/ChangeLog: * read-rtl-function.c (lookup_reg_by_dump_name): Rework to expect regno wrapped in

[Bug fortran/78757] [7 Regression] ICE with function returning a pointer to a character

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78757 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

Re: [PATCH] Emit DECL_EXPR so that type of what pstr.N points to is gimplified (PR fortran/78757)

On Fri, Dec 16, 2016 at 09:31:37PM +0200, Janne Blomqvist wrote: > On Wed, Dec 14, 2016 at 11:55 PM, Jakub Jelinek wrote: > > Hi! > > > > The gimplifier (because of Ada :( ) doesn't recurse to POINTER_TYPE's > > type when gimplifying types, so we need a DECL_EXPR to gimplify

[Bug fortran/78757] [7 Regression] ICE with function returning a pointer to a character

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78757 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Fri Dec 16 19:41:13 2016 New Revision: 243761 URL: https://gcc.gnu.org/viewcvs?rev=243761=gcc=rev Log: PR fortran/78757 * trans-expr.c (gfc_conv_procedure_call): Emit

Re: [PATCH] Emit DECL_EXPR so that type of what pstr.N points to is gimplified (PR fortran/78757)

On Wed, Dec 14, 2016 at 11:55 PM, Jakub Jelinek wrote: > Hi! > > The gimplifier (because of Ada :( ) doesn't recurse to POINTER_TYPE's > type when gimplifying types, so we need a DECL_EXPR to gimplify such > types if they are VLAs. The following patch is an attempt to do that.

Re: [RFA] [PR tree-optimization/33562] [PATCH 1/4] Byte tracking in DSE

On 12/16/2016 06:57 AM, Richard Biener wrote: On Fri, Dec 16, 2016 at 2:54 AM, Jeff Law wrote: + /* REF is a memory write. Go ahead and get its base, size, extent + information and encode the bytes written into LIVE_BYTES. We can + handle any case where we have a

Re: using C++ STL containers in GCC/gfortran source code

On 12/16/2016 06:56 PM, Jakub Jelinek wrote: > On Fri, Dec 16, 2016 at 06:52:03PM +, Pedro Alves wrote: >> GDB has a string_printf function that prints into a std::string, for >> example. Like: >> >> std::string hello = string_printf ("%s", "hello world"); >> >> That's a function that many

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

On Fri, Dec 16, 2016 at 07:00:06PM +, Joseph Myers wrote: > On Fri, 16 Dec 2016, Martin Sebor 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. > > FWIW it's found at least

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

On Fri, 16 Dec 2016, Martin Sebor 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. FWIW it's found at least one real bug in glibc

Re: [RFA] [PR tree-optimization/33562] [PATCH 1/4] Byte tracking in DSE

On 12/16/2016 06:57 AM, Richard Biener wrote: On Fri, Dec 16, 2016 at 2:54 AM, Jeff Law wrote: + { + /* STMT might be partially dead and we may be able to reduce +how many memory locations it stores into. */ + if (live_bytes + &&

Re: [RFA] [PR tree-optimization/33562] [PATCH 1/4] Byte tracking in DSE

On Fri, 16 Dec 2016, Jakub Jelinek wrote: > On Fri, Dec 16, 2016 at 06:35:58PM +, Joseph Myers wrote: > > On Thu, 15 Dec 2016, Jeff Law wrote: > > > > > This version attacks the problem by improving DSE to track stores to > > > memory at > > > a byte level. That allows us to determine if a

Re: Do we really need a CPP manual?

On 12/16/2016 10:06 AM, 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. I reviewed it, on the grounds that a happy rms is good for the

Re: using C++ STL containers in GCC/gfortran source code

On Fri, Dec 16, 2016 at 06:52:03PM +, Pedro Alves wrote: > GDB has a string_printf function that prints into a std::string, for > example. Like: > > std::string hello = string_printf ("%s", "hello world"); > > That's a function that many C++ projects reinvent. If you then want to work

Re: [RFA] [PR tree-optimization/33562] [PATCH 1/4] Byte tracking in DSE

On 12/16/2016 11:43 AM, Jakub Jelinek wrote: On Fri, Dec 16, 2016 at 06:35:58PM +, Joseph Myers wrote: On Thu, 15 Dec 2016, Jeff Law wrote: This version attacks the problem by improving DSE to track stores to memory at a byte level. That allows us to determine if a series of stores

Re: using C++ STL containers in GCC/gfortran source code

On 12/16/2016 06:04 PM, Jakub Jelinek wrote: > On Fri, Dec 16, 2016 at 06:55:12PM +0100, Janus Weil wrote: >> To get to more specific questions ... >> >>> Basically the only STL construct used in the Fortran FE right now >>> seems to be std::swap, and a single instance of std::map in >>>

Re: [PATCH] Remove unused libgfortran functions

On Fri, Dec 16, 2016 at 07:46:01PM +0200, Janne Blomqvist wrote: > On Fri, Dec 16, 2016 at 4:02 PM, FX wrote: > > A few questions: > > > > 1. Regarding gfortran.map, shouldn’t we just flatten out all the symbols > > from GFORTRAN_1.0 to GFORTRAN_1.7 into a single new

[Bug debug/72828] ICE in clone_tree_partial when compiling with -fdebug-types-section

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72828 --- Comment #7 from Nathan Sidwell --- With 78835 patched using Jakub's diff in comment 1, this no longer ices.

Re: using C++ STL containers in GCC/gfortran source code

On 12/16/2016 06:31 PM, Janus Weil wrote: > 2016-12-16 18:53 GMT+01:00 Pedro Alves : >> On 12/16/2016 05:33 PM, Janus Weil wrote: >>> And in particular: How do the current uses of >>> std::string in GCC deal with this problem? (Do they?) >> >> Doesn't look like they do. > >

Re: [RFA] [PR tree-optimization/33562] [PATCH 1/4] Byte tracking in DSE

On 12/16/2016 11:35 AM, Joseph Myers wrote: On Thu, 15 Dec 2016, Jeff Law wrote: This version attacks the problem by improving DSE to track stores to memory at a byte level. That allows us to determine if a series of stores completely covers an earlier store (thus making the earlier store

Re: [RFA] [PR tree-optimization/33562] [PATCH 1/4] Byte tracking in DSE

On Fri, Dec 16, 2016 at 06:35:58PM +, Joseph Myers wrote: > On Thu, 15 Dec 2016, Jeff Law wrote: > > > This version attacks the problem by improving DSE to track stores to memory > > at > > a byte level. That allows us to determine if a series of stores completely > > covers an earlier

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

On Fri, Dec 16, 2016 at 07:29:13PM +0100, Markus Trippelsdorf wrote: > So, to be fair a gave Jakub's patch a try and it has exactly the same > issues for the Linux kernel: sometimes the warning only triggers with > -O3, e.g.: > > % cat sm_ftl.i > int a; > void mtd_read_oob(int); > void

Re: [RFA] [PR tree-optimization/33562] [PATCH 1/4] Byte tracking in DSE

On Thu, 15 Dec 2016, Jeff Law wrote: > This version attacks the problem by improving DSE to track stores to memory at > a byte level. That allows us to determine if a series of stores completely > covers an earlier store (thus making the earlier store dead). Question: suppose you have an

Re: [PATCH] nvptx: do not assume that crtl->is_leaf is unset

On 12/16/2016 09:48 AM, Alexander Monakov wrote: Hi, Until a recent change, crtl->is_leaf was initialized only during IRA startup. On NVPTX, register allocation is not done, so the backend asserts that this field is unset, and recomputes it unconditionally. Now this field can be optionally set

Re: using C++ STL containers in GCC/gfortran source code

2016-12-16 18:53 GMT+01:00 Pedro Alves : > On 12/16/2016 05:33 PM, Janus Weil wrote: > >> "You would need to make sure it uses a xmalloc based allocator first >> or at least calls xmalloc_failed upon allocation failure, otherwise it >> will be a serious regression." >> >> I'm

[Bug rtl-optimization/65618] [5/6/7 Regression] gnat bootstrap comparison failure on mips{,el}-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65618 Eric Botcazou changed: What|Removed |Added Status|WAITING |NEW Component|target

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

On 2016.12.16 at 11:07 -0700, Martin Sebor wrote: > 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

[Bug ipa/77905] [5/6 Regression] ICE at -Os and above in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: in ipa_comdats, at ipa-comdats.c:352)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77905 Jakub Jelinek changed: What|Removed |Added Summary|[5/6/7 Regression] ICE at |[5/6 Regression] ICE at -Os

[Bug debug/77844] [5 Regression] Compilation of simple C++ example exhaust memory

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77844 Jakub Jelinek changed: What|Removed |Added Summary|[5/7 Regression]|[5 Regression] Compilation

New French PO file for 'gcc' (version 6.2.0)

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

[PATCH] Add assertion to _Rb_tree::erase to check for end iterators

This adds assertions to catch assoc.erase(assoc.end()) when _GLIBCXX_ASSERTIONS is defined. Without the assertion it usually leads to a double free, which leads to termination for some mallocs anyway. Because the erase(first, last) form called erase(first++) in a loop I've changed that to bypass

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

> Le 16 déc. 2016 à 19:06, Janne Blomqvist a écrit : > > On Fri, Dec 16, 2016 at 5:50 PM, Dominique d'Humières > wrote: >> Hi Janne, >> >> I have applied your two patches and found that I had to skip the patches for >> resolve.c and match.c due

Re: using C++ STL containers in GCC/gfortran source code

On Dec 16 2016, Janus Weil wrote: thanks for this lengthy comment, but that's really not the kind of discussion I wanna get into here. (And I don't actually agree to all of your points, but that doesn't matter.) Sorry - I misunderstood. Regards, Nick Maclaren.

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

On Fri, Dec 16, 2016 at 11:07:29AM -0700, Martin Sebor wrote: > If your implementation diagnoses the common cases exercised by the > tests I wrote I have no objection to it (not that objecting would > do me any good). Your tests all pass with the patch I've posted, we can surely add further ones

[Bug debug/78835] [7 regression] ICE with -fdebug-types-section and member function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78835 --- Comment #3 from Nathan Sidwell --- started failing with: r240578 | rguenth | 2016-09-28 07:30:19 -0700 (Wed, 28 Sep 2016) | 17 lines 2016-09-28 Richard Biener * dwarf2out.c (struct die_struct): Add removed

[Bug debug/78835] [7 regression] ICE with -fdebug-types-section and member function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78835 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

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: Do we really need a CPP manual?

On 12/16/2016 11:01 AM, Sandra Loosemore wrote: On 12/16/2016 08:45 AM, Joseph Myers wrote: On Thu, 15 Dec 2016, Sandra Loosemore wrote: Looking at the structure of the whole manual, though, I see that most of it is in fact a tutorial on how to use the preprocessor language, like you would

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

On Fri, Dec 16, 2016 at 5:50 PM, Dominique d'Humières wrote: > Hi Janne, > > I have applied your two patches and found that I had to skip the patches for > resolve.c and match.c due to the errors > > ../../p_work/gcc/fortran/resolve.c: In function 'void >

Re: using C++ STL containers in GCC/gfortran source code

On Fri, Dec 16, 2016 at 06:55:12PM +0100, Janus Weil wrote: > To get to more specific questions ... > > > Basically the only STL construct used in the Fortran FE right now > > seems to be std::swap, and a single instance of std::map in > > trans-common.c. > > I see that fortran/trans-common.c

Re: [PATCH 0/4] Improve DSE implementation

On 12/16/2016 06:32 AM, Richard Biener wrote: On Fri, Dec 16, 2016 at 2:54 AM, Jeff Law wrote: This is a 4 part patchkit to address various deficiencies in our DSE implementation. BZ33562 was the inspiration for this work. 33562 is a low priority regression that's been

Re: Do we really need a CPP manual?

On 12/16/2016 08:45 AM, Joseph Myers wrote: On Thu, 15 Dec 2016, Sandra Loosemore wrote: Looking at the structure of the whole manual, though, I see that most of it is in fact a tutorial on how to use the preprocessor language, like you would find in a C programming book. Is this a useful

[Bug debug/78835] [7 regression] ICE with -fdebug-types-section and member function

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

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

On Fri, Dec 16, 2016 at 5:34 PM, Andre Vehreschild wrote: > Hi Janne, hi all, > > as promised please find attached the change from int32 to size_t for the > caf-libraries. Because the caf-libraries do not require special notions > indicated by negative values I went for using size_t

Re: using C++ STL containers in GCC/gfortran source code

To get to more specific questions ... > Basically the only STL construct used in the Fortran FE right now > seems to be std::swap, and a single instance of std::map in > trans-common.c. I see that fortran/trans-common.c has: #define INCLUDE_MAP and apparently there is also a INCLUDE_STRING

Re: using C++ STL containers in GCC/gfortran source code

On 12/16/2016 05:33 PM, Janus Weil wrote: > "You would need to make sure it uses a xmalloc based allocator first > or at least calls xmalloc_failed upon allocation failure, otherwise it > will be a serious regression." > > I'm really not an expert on GCC's memory management principles and how >

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

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 minor changes to exception_ptr implementation.

[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78817 --- Comment #19 from Martin Sebor --- (In reply to dave.anglin from comment #18) > The change didn't fix build on hppa-linux: This should be fixed in the patch referenced in comment #16, though the patch is yet to be reviewed and judging by the

[PATCH] noipa attribute (was Re: How to avoid constant propagation into functions?)

Hi! On Fri, Dec 16, 2016 at 04:53:07PM +0100, Martin Jambor wrote: > On Fri, Dec 16, 2016 at 02:31:48PM +0100, Jakub Jelinek wrote: > > Suggestions how to test that IPA-SRA and IPA-PTA aren't happening? > > Anything else we need to cover? > I would use some test from

  1   2   3   >