[Bug fortran/83560] list-directed formatting of INTEGER is missing plus on output when output open with SIGN='PLUS'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83560 --- Comment #7 from Jerry DeLisle --- Patch posted here: https://gcc.gnu.org/ml/fortran/2017-12/msg00089.html

[Bug target/83585] New: [8 Regression] Assembler messages: Error: can't resolve `.text' {.text section} - `.LCOLDB0' {.text.unlikely section}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83585 Bug ID: 83585 Summary: [8 Regression] Assembler messages: Error: can't resolve `.text' {.text section} - `.LCOLDB0' {.text.unlikely section} Product: gcc

[Bug rtl-optimization/83480] [8 Regression] ICE in create_block_for_bookkeeping, at sel-sched.c:4557

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83480 --- Comment #3 from Arseny Solokha --- Likely a duplicate of PR80463.

[Bug other/83520] format string bug in libvtv

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83520 --- Comment #3 from Touma Hatano --- Sorry for misleading. My point was that if we can replace snprintf (program_name, sizeof (program_name), program_invocation_name); with snprintf (program_name, sizeof (program_name), "%s",

[Bug c/83584] "ISO C forbids conversion of object pointer to function pointer type" -- no, not really

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584 --- Comment #4 from Keith Thompson --- I'm aware that the standard has not changed in this area from C90 to C99 to C11. The conversion is undefined behavior, not a constraint violation, in all three editions. If the conversion is forbidden,

[Bug c/83584] "ISO C forbids conversion of object pointer to function pointer type" -- no, not really

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

[Bug c/83584] "ISO C forbids conversion of object pointer to function pointer type" -- no, not really

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584 --- Comment #2 from Andrew Pinski --- Your reading of the spec is different than the GCC folks read it. See PR 11234 which requested the error in the first place. Note C11 and C89/C90 has not changed in this area as far as I can tell.

[Bug c/83584] "ISO C forbids conversion of object pointer to function pointer type" -- no, not really

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584 --- Comment #1 from Keith Thompson --- Tested on x86_64 Ubuntu 17.04, gcc 7.1.0 built from source

[Bug c/83584] New: "ISO C forbids conversion of object pointer to function pointer type" -- no, not really

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584 Bug ID: 83584 Summary: "ISO C forbids conversion of object pointer to function pointer type" -- no, not really Product: gcc Version: 7.1.0 Status: UNCONFIRMED

[Bug c++/83533] error: no type named 'X' in 'using = ...'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83533 --- Comment #4 from Jonathan Wakely --- This was a bug in GCC 4.7.x which is fixed in GCC 4.8.0 We already fixed it, and do not support GCC 4.7 (or anything older than GCC 6), so there's nothing more we can do. Either use the workaround or use

[Bug libstdc++/83237] Values returned by std::poisson_distribution are not distributed correctly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83237 --- Comment #5 from paolo at gcc dot gnu.org --- Author: paolo Date: Sun Dec 24 22:08:52 2017 New Revision: 255993 URL: https://gcc.gnu.org/viewcvs?rev=255993=gcc=rev Log: 2017-12-24 Michele Pezzutti PR

[Bug tree-optimization/83581] [8 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.c:2397

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83581 Andrew Pinski changed: What|Removed |Added Target||x86_64-linux-gnu

[Bug ipa/83582] GCC is unable to fold the code of identical lambda-expressions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83582 --- Comment #2 from Andrew Pinski --- Most likely because the requirement that two different lambdas need not to compare equal.

[Bug ipa/83582] GCC is unable to fold the code of identical lambda-expressions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83582 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization --- Comment #1 from

[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 --- Comment #20 from Jim Wilson --- I don't see the distinction here. Ia64 has instructions that operate on 32-bit values too, like cmp4. On sparc, given this testcase int sub (int i, int j, int k) { return i + j + k; } the compiler

[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 --- Comment #19 from James Clarke --- (In reply to Jim Wilson from comment #16) > That referred patch was written by Eric Botcazou for PR59461 which is for > SPARC, which operates same as Itanium, the upper 32-bits of a 32-bit value > in a

[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 --- Comment #18 from Jim Wilson --- SPARC defines WORD_REGISTER_OPERATIONS, and works the same as ia64. The upper bits of a 64-bit register after a 32-bit operation are don't care bits.

[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 --- Comment #17 from James Clarke --- (In reply to Eric Botcazou from comment #15) > > Thanks Jim, that makes sense. It seems to me that WORD_REGISTER_OPERATIONS > > should still be true on ia64 given the description in the documentation. > > I

[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 --- Comment #16 from Jim Wilson --- That referred patch was written by Eric Botcazou for PR59461 which is for SPARC, which operates same as Itanium, the upper 32-bits of a 32-bit value in a 64-bit reg are undefined. So it does not appear to be

[Bug c++/83583] New: ICE in synthesize_implicit_template_parm, at cp/parser.c:38794

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83583 Bug ID: 83583 Summary: ICE in synthesize_implicit_template_parm, at cp/parser.c:38794 Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal

[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 --- Comment #15 from Eric Botcazou --- > Thanks Jim, that makes sense. It seems to me that WORD_REGISTER_OPERATIONS > should still be true on ia64 given the description in the documentation. I disagree, WORD_REGISTER_OPERATIONS means that the

[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 --- Comment #14 from Segher Boessenkool --- (In reply to Jim Wilson from comment #11) > This part > > >r358 is known to have the high half zero: > > 22: r358:DI=r357:SI#0^r341:SI#0 > > is wrong. The upper bits of both registers are unknown

[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83565 James Clarke changed: What|Removed |Added Attachment #42961|0 |1 is obsolete|

[Bug ipa/83582] New: GCC is unable to fold the code of identical lambda-expressions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83582 Bug ID: 83582 Summary: GCC is unable to fold the code of identical lambda-expressions Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

[Bug fortran/83560] list-directed formatting of INTEGER is missing plus on output when output open with SIGN='PLUS'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83560 --- Comment #6 from urbanjost at comcast dot net --- Thanks! As always, I am astonished at what has been accomplished. Fortran's viability itself depends so much on the availability of an open compiler.

[Bug c++/83533] error: no type named 'X' in 'using = ...'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83533 --- Comment #3 from Rostislav Povelikin --- (In reply to Jonathan Wakely from comment #2) > GCC 4.7.x has not been maintained or supported by the upstream GCC project > for several years, and this is already fixed in GCC 4.8.0 Hi Jonathan,

[Bug fortran/83567] Parametrized derived types: Segmentation fault when assigning a function return value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83567 --- Comment #2 from Paul Thomas --- Created attachment 42962 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42962=edit A partial fix for the PR The attached patch clears the ICE and yields the correct result. However, there is still a

[Bug fortran/83567] Parametrized derived types: Segmentation fault when assigning a function return value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83567 Paul Thomas changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug c++/41874] Incorrect "dereferencing type-punned pointer will break strict-aliasing rules" warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41874 Jonathan Wakely changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED

[Bug rtl-optimization/83581] New: [8 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.c:2397

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83581 Bug ID: 83581 Summary: [8 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.c:2397 Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords:

[Bug tree-optimization/83580] New: Wrong constant folding

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83580 Bug ID: 83580 Summary: Wrong constant folding Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization

[Bug c++/41874] Incorrect "dereferencing type-punned pointer will break strict-aliasing rules" warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41874 --- Comment #15 from Aso Renji --- (In reply to Jonathan Wakely from comment #14) > What do you mean by "same problem"? The original testcase does not produce a > warning with GCC 6.3.0 No, this warning still appear if (and only if) you use -O2

[Bug libstdc++/83450] FAIL: 21_strings/basic_string/pthread18185.cc (test for excess errors)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83450 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug libstdc++/83450] FAIL: 21_strings/basic_string/pthread18185.cc (test for excess errors)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83450 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Sun Dec 24 09:17:38 2017 New Revision: 255992 URL: https://gcc.gnu.org/viewcvs?rev=255992=gcc=rev Log: PR libstdc++/83450 avoid -Wreturn-type warning in test PR libstdc++/83450

[Bug libstdc++/83538] std::match_results C++14 conformance issue: reference != value_type

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

[Bug c++/83533] error: no type named 'X' in 'using = ...'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83533 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug libstdc++/68735] FAIL: libstdc++-prettyprinters/libfundts.cc print ab

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68735 --- Comment #3 from Jonathan Wakely --- Those Python exceptions come from GDB, but I'm not sure why.

[Bug target/83008] [performance] Is it better to avoid extra instructions in data passing between loops?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83008 --- Comment #18 from sergey.shalnov at intel dot com --- Yes, I agree that vector_store stage has it’s own vectorization cost. And each vector_store has vector_construction stage. These stages are different in gcc slp (as you know). To better

[Bug fortran/83540] [8 Regression] Invalid code with MATMUL, -fno-realloc-lhs -ffrontend-optimize

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83540 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned

[Bug middle-end/83557] missing last char in printf fmt string

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83557 --- Comment #3 from m68k --- Thanks for the feedback of this forgotten/unexpected behavior. The funny part of this is, that the rules are not easy to adopt see what printf("%c\r\n", 'A');    5      .LC1:    6 0002 25630D0A        

[Bug middle-end/83557] missing last char in printf fmt string

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83557 --- Comment #2 from m68k --- Thanks for the feedback of this forgotten/unexpected behavior. The funny part of this is, that the rules are not easy to adopt see what printf("%c\r\n", 'A'); 5.LC1: 6 0002 25630D0A

[Bug libstdc++/83450] FAIL: 21_strings/basic_string/pthread18185.cc (test for excess errors)

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

[Bug c++/41874] Incorrect "dereferencing type-punned pointer will break strict-aliasing rules" warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41874 --- Comment #14 from Jonathan Wakely --- (In reply to Aso Renji from comment #13) > Still have same problem in g++ 6.3.0. So, please reopen this bug. What do you mean by "same problem"? The original testcase does not produce a warning with GCC

[Bug libstdc++/83511] Missing default argument for basic_string_view::substr

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83511 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid

[Bug c++/83484] constexpr not evaluated at compile time

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83484 Jonathan Wakely changed: What|Removed |Added Keywords|link-failure|accepts-invalid

[Bug c++/83473] pragma problems with raw string literals

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