[Bug preprocessor/106767] Failure to detect recursive macro calls due to _Pragma(pop_macro)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106767 --- Comment #3 from Alexey Izbyshev --- > I can make newer one recognize _Pragma only by unquoting the string literal I've investigated this strange behavior because MSVC docs do claim that C99 _Pragma is properly supported[1]. It turned out

[Bug preprocessor/106767] Failure to detect recursive macro calls due to _Pragma(pop_macro)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106767 --- Comment #2 from Alexey Izbyshev --- Old MSVC doesn't support _Pragma, and I can make newer one recognize _Pragma only by unquoting the string literal, so the first test case becomes: // Removed stringizing in _Pragma #define P(x)

[Bug preprocessor/106767] Failure to detect recursive macro calls due to _Pragma(pop_macro)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106767 --- Comment #1 from Andrew Pinski --- How does msvc handle this? Since gcc is trying to be compatible with msvc here.

[Bug preprocessor/106767] New: Failure to detect recursive macro calls due to _Pragma(pop_macro)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106767 Bug ID: 106767 Summary: Failure to detect recursive macro calls due to _Pragma(pop_macro) Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal

[Bug fortran/93482] ICE in gfc_resolve_character_array_constructor, at fortran/array.c:2096

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93482 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED

[Bug ipa/106627] Exception from multiversion function cannot be caught

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106627 --- Comment #2 from Simon Rainer --- Created attachment 53518 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53518=edit Proposed patch: Set TREE_NOTHROW correctly I think I identified the issue and found a fix.

[Bug fortran/84693] scalar DT not broadcast across an array in an initialization expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84693 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to work||10.4.0, 11.3.0, 12.2.0

[Bug libstdc++/106766] New: zip_view::_Iterator/_Sentinel's operator- use make_unsigned_t

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106766 Bug ID: 106766 Summary: zip_view::_Iterator/_Sentinel's operator- use make_unsigned_t Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal

[Bug target/106763] Armv8.2 vmov.f16 instruction sometimes causes SIGILL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763 --- Comment #2 from George Pee --- Forgot to mention that I'm building 32-bit.

[Bug c/106764] ICE on invalid code in tree check: expected function_type or method_type, have error_mark in gimplify_call_expr, at gimplify.cc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106764 Andrew Pinski changed: What|Removed |Added Severity|normal |trivial

[Bug c/106765] ICE (invalid code) in tree check: expected class 'type', have 'exceptional' (error_mark) in create_tmp_from_val, at gimplify.cc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106765 Andrew Pinski changed: What|Removed |Added Keywords||error-recovery, |

[Bug c/106765] New: ICE (invalid code) in tree check: expected class 'type', have 'exceptional' (error_mark) in create_tmp_from_val, at gimplify.cc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106765 Bug ID: 106765 Summary: ICE (invalid code) in tree check: expected class 'type', have 'exceptional' (error_mark) in create_tmp_from_val, at gimplify.cc Product: gcc

[Bug c/106764] New: ICE on invalid code in tree check: expected function_type or method_type, have error_mark in gimplify_call_expr, at gimplify.cc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106764 Bug ID: 106764 Summary: ICE on invalid code in tree check: expected function_type or method_type, have error_mark in gimplify_call_expr, at gimplify.cc Product: gcc

[Bug target/106763] Armv8.2 vmov.f16 instruction sometimes causes SIGILL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763 --- Comment #1 from George Pee --- I was using gcc-12, but I was also able to reproduce this issue using the sample program above and gcc-10.

[Bug target/106763] New: Armv8.2 vmov.f16 instruction sometimes causes SIGILL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763 Bug ID: 106763 Summary: Armv8.2 vmov.f16 instruction sometimes causes SIGILL Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3

[Bug c/106762] New: incorrect array bounds warning (-Warray-bounds) at -O2 on memset()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106762 Bug ID: 106762 Summary: incorrect array bounds warning (-Warray-bounds) at -O2 on memset() Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal

[Bug fortran/102043] [10/11 Regression] Wrong array types used for negative stride accesses, gfortran.dg/vector_subscript_1.f90 FAILs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 --- Comment #53 from Mikael Morin --- (In reply to Mikael Morin from comment #52) > I posted a mostly-finished patch at [1] to restore array indexing of > descriptor arrays. I forgot to add a link for [1]:

[Bug fortran/102043] [10/11 Regression] Wrong array types used for negative stride accesses, gfortran.dg/vector_subscript_1.f90 FAILs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 Mikael Morin changed: What|Removed |Added Assignee|mikael at gcc dot gnu.org |unassigned at gcc dot gnu.org

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012 Mikael Morin changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org

[Bug c++/95298] [10/11/12/13 Regression] sorry, unimplemented: mangling record_type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95298 janpmoeller at gmx dot de changed: What|Removed |Added CC||janpmoeller at gmx dot de

[Bug tree-optimization/103798] memchr with a (small) constant string should be expanded inline.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103798 Jan-Benedict Glaw changed: What|Removed |Added CC||jbg...@lug-owl.de --- Comment #4