[Bug c++/67244] internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:1801

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67244 Emil Eriksson changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE

[Bug tree-optimization/67242] Missing optimization with float IV in SCEV-CCP

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67242 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|

[Bug middle-end/67241] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67241 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[Bug tree-optimization/67227] [6 regression] stage2 ada compiler miscompiled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67227 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0

[Bug target/67226] Incorrect code generated for tail call, where parameters are structs passed by value, -O2 is used, and target is ARM

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67226 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target|

[Bug middle-end/67222] [4.9/5/6 Regression] ICE in gimple_call_arg with bogus posix_memalign

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67222 --- Comment #2 from Richard Biener --- lower_builtin_setjmp has similar issues.

[Bug tree-optimization/67221] [6 Regression] ICE at -Os and above on x86_64-linux-gnu: Segmentation fault (program cc1)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67221 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned

[Bug fortran/67219] [6 Regression] Incorrect conversion warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67219 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0

[Bug middle-end/67222] [4.9/5/6 Regression] ICE in gimple_call_arg with bogus posix_memalign

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67222 --- Comment #3 from Marek Polacek --- Yeah, but that for some reason doesn't ICE.

[Bug tree-optimization/67221] [6 Regression] ICE at -Os and above on x86_64-linux-gnu: Segmentation fault (program cc1)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67221 --- Comment #5 from Richard Biener --- Ok, so we have e_17 = e_3 + 1; and e_3 value-numbers to e_17 (for some reason). match-and-simplify then recursively matches ((e_3 + 1) + 1) + 1 ... Visiting BB 8 SCC consists of: e_3 e_17 Starting iterat

[Bug c++/67245] New: static_assert on inline function gives an error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67245 Bug ID: 67245 Summary: static_assert on inline function gives an error Product: gcc Version: 4.9.2 URL: http://stackoverflow.com/questions/32045025/static-ass ert-on-i

[Bug c++/67245] static_assert on inline function gives an error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67245 --- Comment #1 from Andrew Pinski --- Oh looks like "weak" is getting in the way here.

[Bug sanitizer/67204] documentation for sanitizer missing/incomplete

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67204 Yury Gribov changed: What|Removed |Added CC||y.gribov at samsung dot com --- Comment #6

[Bug c++/67245] static_assert on inline function gives an error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67245 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug c++/67240] [concepts] Implicit conversion constraints are not respected

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67240 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug tree-optimization/43174] Teaching SCEV about ADDR_EXPR causes regression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43174 --- Comment #3 from amker at gcc dot gnu.org --- Note for the three levels of loop example, GCC chooses one IV for both j and k loops, thus generates pretty clean output on x86_64 with O2. For the simple example, now gcc can eliminate compariso

[Bug tree-optimization/43174] Teaching SCEV about ADDR_EXPR causes regression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43174 --- Comment #4 from amker at gcc dot gnu.org --- Looks the ADDR_EXPR issue is fixed by revision 185129.

[Bug target/67246] New: MIPS: lw (load word) is generated for byte bitfield, leading to unaligned access

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67246 Bug ID: 67246 Summary: MIPS: lw (load word) is generated for byte bitfield, leading to unaligned access Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity

[Bug target/67246] MIPS: lw (load word) is generated for byte bitfield, leading to unaligned access

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67246 --- Comment #1 from Andrew Pinski --- This testcase does not test what you think it tests. Since t is on the stack, the alignment can (and most likely will be) aligned to a 4 byte boundary. Also the struct tester has an alignment of 2 bytes so

[Bug target/67246] MIPS: lw (load word) is generated for byte bitfield, leading to unaligned access

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67246 --- Comment #2 from Thomas Martitz --- Thanks for your immediate reply. In trying to provide a better test case I think I've found what the culprit is. The full iphdr defintion is: struct iphdr { #if defined(__LITTLE_ENDIAN_BITFIELD) _

[Bug target/67246] MIPS: lw (load word) is generated for byte bitfield, leading to unaligned access

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

[Bug target/67246] MIPS: lw (load word) is generated for byte bitfield, leading to unaligned access

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67246 Thomas Martitz changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID

[Bug target/67246] MIPS: lw (load word) is generated for byte bitfield, leading to unaligned access

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

[Bug target/67246] MIPS: lw (load word) is generated for byte bitfield, leading to unaligned access

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67246 Thomas Martitz changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID

[Bug sanitizer/67204] documentation for sanitizer missing/incomplete

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67204 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Commen

[Bug target/67246] MIPS: lw (load word) is generated for byte bitfield, leading to unaligned access

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67246 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/67244] [5/6 Regression] internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:1801

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67244 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug c++/67247] New: ICE on std::forward args&& inside nested lambda function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67247 Bug ID: 67247 Summary: ICE on std::forward args&& inside nested lambda function Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Prior

[Bug c++/67247] ICE on std::forward args&& inside nested lambda function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67247 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug target/67127] [ARM] Avoiding odd-number ldrd/strd in movdi introduced a regression on armeb-linux-gnueabihf

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67127 --- Comment #2 from Yvan Roux --- Author: yroux Date: Mon Aug 17 11:22:49 2015 New Revision: 226937 URL: https://gcc.gnu.org/viewcvs?rev=226937&root=gcc&view=rev Log: 2015-08-17 Yvan Roux Backport from mainline: 2015-08-12 Y

[Bug target/67127] [ARM] Avoiding odd-number ldrd/strd in movdi introduced a regression on armeb-linux-gnueabihf

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67127 Yvan Roux changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67133 --- Comment #26 from Martin Jambor --- If fntype specifies the ABI then when we know we will be calling a different function (which might have its prototype modified for example by parameter removal), then we should set the fntype too. And furth

[Bug sanitizer/67204] documentation for sanitizer missing/incomplete

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67204 Dmitry Vyukov changed: What|Removed |Added CC||dvyukov at google dot com --- Comment #8

[Bug sanitizer/67204] documentation for sanitizer missing/incomplete

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67204 --- Comment #9 from Yury Gribov --- (In reply to Dmitry Vyukov from comment #8) > (In reply to Manuel López-Ibáñez from comment #7) > > I'm not saying that anyone should stop working on what they are doing to > > implement this, but if a voluntee

[Bug sanitizer/67204] documentation for sanitizer missing/incomplete

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67204 --- Comment #10 from Yury Gribov --- (In reply to Marek Polacek from comment #5) > (In reply to smagnet from comment #3) > > Moreover, the undefined behavior sanitizer runtime options (UBSAN_OPTIONS, > > as described here > >

[Bug c++/67248] New: Variable template cannot be used as dependent name

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67248 Bug ID: 67248 Summary: Variable template cannot be used as dependent name Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component

[Bug sanitizer/67204] documentation for sanitizer missing/incomplete

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67204 --- Comment #11 from Marek Polacek --- (In reply to Yury Gribov from comment #10) > Are you sure? I've been using it with libubsan in GCC trunk... Ah, ok, it seems to work: $ UBSAN_OPTIONS=print_stacktrace=1 ./a.out r.c:6:10: runtime error: si

[Bug c++/67248] Variable template cannot be used as dependent name

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67248 Vittorio Romeo changed: What|Removed |Added CC||vittorio.romeo at outlook dot com ---

[Bug c++/67249] New: [concepts] ICE parsing f(pair)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67249 Bug ID: 67249 Summary: [concepts] ICE parsing f(pair) Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assign

[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67133 --- Comment #27 from Richard Biener --- (In reply to Martin Jambor from comment #26) > If fntype specifies the ABI then when we know we will be calling a > different function (which might have its prototype modified for > example by parameter rem

[Bug tree-optimization/67221] [6 Regression] ICE at -Os and above on x86_64-linux-gnu: Segmentation fault (program cc1)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67221 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug tree-optimization/67221] [6 Regression] ICE at -Os and above on x86_64-linux-gnu: Segmentation fault (program cc1)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67221 --- Comment #6 from Richard Biener --- Author: rguenth Date: Mon Aug 17 14:17:33 2015 New Revision: 226938 URL: https://gcc.gnu.org/viewcvs?rev=226938&root=gcc&view=rev Log: 2015-08-17 Richard Biener PR tree-optimization/67221

[Bug c++/65974] [5/6 Regression] Bogus deprecated-declarations warnings for inline definitions of deprecated virtual methods

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65974 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67133 --- Comment #28 from Martin Jambor --- I see, thinking about signature changes, I forgot about the situations where we do not have the body of the callee in the first place.

[Bug debug/67192] Backward-goto in loop can get wrong line number

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67192 Andreas Arnez changed: What|Removed |Added CC||dmalcolm at redhat dot com --- Comment #

[Bug c++/67104] [5 regression] Constant expression factory function initializes std::array with static storage duration strangely

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67104 --- Comment #11 from Jason Merrill --- Author: jason Date: Mon Aug 17 15:44:29 2015 New Revision: 226940 URL: https://gcc.gnu.org/viewcvs?rev=226940&root=gcc&view=rev Log: PR c++/67104 * constexpr.c (cxx_eval_array_reference): Ha

[Bug c++/65734] Yet another case of lost alignment by stor_layout

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65734 --- Comment #5 from Jason Merrill --- Author: jason Date: Mon Aug 17 15:44:35 2015 New Revision: 226941 URL: https://gcc.gnu.org/viewcvs?rev=226941&root=gcc&view=rev Log: PR c++/65734 gcc/ * stor-layout.c (layout_type): Layout th

[Bug fortran/67250] New: gfortran does not faithfully preprocess the way cpp does

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67250 Bug ID: 67250 Summary: gfortran does not faithfully preprocess the way cpp does Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: blocker Prio

[Bug fortran/67251] New: gfortran does not faithfully preprocess the way cpp does

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67251 Bug ID: 67251 Summary: gfortran does not faithfully preprocess the way cpp does Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: blocker Prio

[Bug c++/66121] [5 Regression] internal compiler error: in strip_typedefs, at cp/tree.c:1369

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66121 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Bug c++/55004] [meta-bug] constexpr issues

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 67104, which changed state. Bug 67104 Summary: [5 regression] Constant expression factory function initializes std::array with static storage duration strangely https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67104

[Bug c++/67104] [5 regression] Constant expression factory function initializes std::array with static storage duration strangely

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67104 Jason Merrill changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|---

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67250 --- Comment #1 from Andrew Pinski --- See the option -traditional-cpp.

[Bug fortran/67251] gfortran does not faithfully preprocess the way cpp does

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67251 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67250 --- Comment #2 from Manuel López-Ibáñez --- *** Bug 67251 has been marked as a duplicate of this bug. ***

[Bug c++/67216] false is still a null pointer constant

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67216 Paolo Carlini changed: What|Removed |Added Keywords|accepts-invalid |rejects-valid Status|NEW

[Bug c/67224] UTF-8 support for identifier names in GCC

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224 --- Comment #6 from Eric --- >From the webpage (current as of Aug 17, 2015) http://www.gnu.org/software/libiconv/ under *Details* it is described that the library provides support for the following encodings: Full Unicode UTF-8

[Bug c++/67064] Register asm variable broken

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 --- Comment #21 from Jason Merrill --- (In reply to Daniel Gutson from comment #20) > I don't have a @gcc.gnu.org account. Should I simply send the attachment? Sure. > Otherwise please assign this to me for me if it is still possible. Done. >

[Bug c++/67064] Register asm variable broken

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 --- Comment #22 from Daniel Gutson --- (In reply to Jason Merrill from comment #21) > (In reply to Daniel Gutson from comment #20) > > I don't have a @gcc.gnu.org account. Should I simply send the attachment? > > Sure. > > > Otherwise please as

[Bug c++/67244] [5/6 Regression] internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:1801

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67244 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Bug c++/67104] [5 regression] Constant expression factory function initializes std::array with static storage duration strangely

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67104 --- Comment #13 from Jason Merrill --- Author: jason Date: Mon Aug 17 18:42:04 2015 New Revision: 226949 URL: https://gcc.gnu.org/viewcvs?rev=226949&root=gcc&view=rev Log: PR c++/67104 * constexpr.c (array_index_cmp, find_array_c

[Bug c++/67244] [5/6 Regression] internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:1801

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67244 --- Comment #5 from Jason Merrill --- Author: jason Date: Mon Aug 17 18:42:26 2015 New Revision: 226951 URL: https://gcc.gnu.org/viewcvs?rev=226951&root=gcc&view=rev Log: PR c++/67244 * pt.c (tsubst_copy_and_build): Call insert_p

[Bug c++/67244] [5/6 Regression] internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:1801

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67244 --- Comment #4 from Jason Merrill --- Author: jason Date: Mon Aug 17 18:42:09 2015 New Revision: 226950 URL: https://gcc.gnu.org/viewcvs?rev=226950&root=gcc&view=rev Log: PR c++/67244 * pt.c (tsubst_copy_and_build): Call insert_p

[Bug c/67224] UTF-8 support for identifier names in GCC

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224 --- Comment #7 from Eric --- Please look at the Raspberry Pi forum post linked in the original report for more information about testing this patch. As the text describes there, the command line options -finput-charset=UTF-8 -fextended-ide

[Bug c/67224] UTF-8 support for identifier names in GCC

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224 --- Comment #8 from Eric --- Created attachment 36196 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36196&action=edit Test program with UTF-8 identifiers... Compile this test program using gcc \ -finput-charset=UTF-8 -fextended-iden

[Bug c++/67064] Register asm variable broken

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 --- Comment #23 from Jason Merrill --- (In reply to Daniel Gutson from comment #22) > (In reply to Jason Merrill from comment #21) > > (In reply to Daniel Gutson from comment #20) > > > FWIW, I've been listed in the MAINTAINER list in the past wh

[Bug c/67224] UTF-8 support for identifier names in GCC

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224 --- Comment #9 from Manuel López-Ibáñez --- (In reply to Eric from comment #7) > also contains example UTF-8 C99 input files which can be used to test the > compiler. The one-line patch submitted above has also been tested in the > sense that th

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67250 --- Comment #3 from Jeff Hammond --- Unfortunately, this does not change anything. > gfortran-5 -traditional-cpp -I. -E source.F # 1 "source.F" # 1 "" # 1 "" # 1 "source.F" C C OLD SCHOOL COMMENTS C subroutine xyz(stuff) implicit no

[Bug c++/58907] [c++11] ICE in gimplify_var_or_parm_decl, at gimplify.c:NNNN

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58907 --- Comment #3 from Markus Trippelsdorf --- Actually a dup of 67244, so fixed, too. *** This bug has been marked as a duplicate of bug 67244 ***

[Bug c++/67244] [5/6 Regression] internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:1801

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67244 Markus Trippelsdorf changed: What|Removed |Added CC||ppluzhnikov at google dot com ---

[Bug c/67224] UTF-8 support for identifier names in GCC

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug c++/62272] Gimplify throws error on method call from inside nested lambdas

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62272 Markus Trippelsdorf changed: What|Removed |Added Known to work||5.2.1, 6.0 Known to fail|

[Bug c++/58907] [c++11] ICE in gimplify_var_or_parm_decl, at gimplify.c:NNNN

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58907 --- Comment #4 from Markus Trippelsdorf --- Sorry for the noise. It is a dup of PR62272 after all. Fixed for gcc-5 and gcc-6 by r226950 and r226951. *** This bug has been marked as a duplicate of bug 62272 ***

[Bug c++/62272] Gimplify throws error on method call from inside nested lambdas

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62272 --- Comment #7 from Markus Trippelsdorf --- *** Bug 58907 has been marked as a duplicate of this bug. ***

[Bug c++/54367] [meta-bug] lambda expressions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 62272, which changed state. Bug 62272 Summary: Gimplify throws error on method call from inside nested lambdas https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62272 What|Removed |Added ---

[Bug c++/67244] [5/6 Regression] internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:1801

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67244 Bug 67244 depends on bug 62272, which changed state. Bug 62272 Summary: Gimplify throws error on method call from inside nested lambdas https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62272 What|Removed |Added ---

[Bug c++/62272] Gimplify throws error on method call from inside nested lambdas

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62272 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Bug c++/62272] Gimplify throws error on method call from inside nested lambdas

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62272 --- Comment #9 from Markus Trippelsdorf --- (In reply to Jason Merrill from comment #8) > Fixed for 5.3. Well, 4.9.3 still ICEs.

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67250 --- Comment #4 from Andrew Pinski --- (In reply to Jeff Hammond from comment #3) > Unfortunately, this does not change anything. > I saying gfortran defaults to that and you can use that option to cpp to get the same behavior. > > gfortra

[Bug c/67224] UTF-8 support for identifier names in GCC

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224 --- Comment #11 from joseph at codesourcery dot com --- Sorry, glibc iconv (not libiconv) doesn't handle "C99". So your patch would not work on any GNU host in normal configurations of GCC (libiconv is a completely separate package and is only

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67250 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|

[Bug c++/62272] Gimplify throws error on method call from inside nested lambdas

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62272 --- Comment #10 from Jason Merrill --- (In reply to Markus Trippelsdorf from comment #9) > (In reply to Jason Merrill from comment #8) > > Fixed for 5.3. > > Well, 4.9.3 still ICEs. Yes, but this isn't a regression.

[Bug c++/66957] [4.9/5/6 Regression] incorrect "is protected within this context" error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66957 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Depends

[Bug c++/66919] [5 Regression] C++14 ICE during error reporting

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66919 --- Comment #1 from Jason Merrill --- Author: jason Date: Mon Aug 17 21:34:50 2015 New Revision: 226955 URL: https://gcc.gnu.org/viewcvs?rev=226955&root=gcc&view=rev Log: PR c++/66919 * pt.c (tsubst_copy): Pass complain to mark_u

[Bug c++/67216] false is still a null pointer constant

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67216 --- Comment #3 from paolo at gcc dot gnu.org --- Author: paolo Date: Mon Aug 17 21:40:07 2015 New Revision: 226956 URL: https://gcc.gnu.org/viewcvs?rev=226956&root=gcc&view=rev Log: /cp 2015-08-17 Paolo Carlini PR c++/67216 *

[Bug c++/67216] false is still a null pointer constant

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67216 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug c++/67252] New: Demangler fails on template conversion operator

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67252 Bug ID: 67252 Summary: Demangler fails on template conversion operator Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug c/67224] UTF-8 support for identifier names in GCC

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224 --- Comment #12 from Eric --- I'm glad to know people like Joseph are working on UTF-8 in gcc. Last year I spent a week adding UTF-8 input support to pcc. At that time Microsoft Studio and clang already supported UTF-8 input files and I expecte

[Bug tree-optimization/67253] New: ICE at -O3 on x86_64-linux-gnu (verify_gimple failed)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67253 Bug ID: 67253 Summary: ICE at -O3 on x86_64-linux-gnu (verify_gimple failed) Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Componen

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67250 Jeff Hammond changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67250 --- Comment #7 from Jeff Hammond --- And your "obvious workaround" is in fact not one because it changes the behavior of gfortran for Fortran source code and breaks the build in another way. And even if it did solve the problem, why not make it

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

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

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67250 --- Comment #9 from Jeff Hammond --- First, you will not accept the fusion of cpp+gfortran behavior as a feature request? Is there a reason other than you do not want to do it because you are already busy? Second, true, but that doesn't stop gc

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67250 --- Comment #10 from Andrew Pinski --- (In reply to Jeff Hammond from comment #9) > First, you will not accept the fusion of cpp+gfortran behavior as a feature > request? Is there a reason other than you do not want to do it because you > are al

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67250 --- Comment #11 from Steve Kargl --- On Tue, Aug 18, 2015 at 06:03:00AM +, jeff.science at gmail dot com wrote: > > In short, "it's not in the standard, therefore it's fine to break user > experience" seems pretty weak here. It's fine if yo