https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107360
--- Comment #4 from Alexey Izbyshev ---
(In reply to Martin Uecker from comment #3)
> I think there there are cases were variably modified
> return types are allowed in ISO C:
>
> void f(int n, double (*(bar(void)))[n])
> {
> double (*p)[n]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107360
--- Comment #2 from Alexey Izbyshev ---
(In reply to Andrew Pinski from comment #1)
> Maybe this should be invalid code ...
Yes, I think it should be invalid. VLAs are not allowed in function return
types in C. VLAs in C++ are a GCC extension,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107360
Bug ID: 107360
Summary: ICE on sizeof(*f(x)) when f's (deduced) return type is
a pointer to VLA
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106767
--- Comment #5 from Alexey Izbyshev ---
(In reply to Richard Biener from comment #4)
> Is there a public specification of the Microsoft extension and how it is
> supposed to behave with recursion or is the recursion behavior specified
> by the C
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 th
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) _Pragma(x)
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105355
--- Comment #3 from Alexey Izbyshev ---
(In reply to Martin Liška from comment #2)
Yes, "gcc test.h -o test.pch" uses the separate spelling of "--output-pch=" in
cc1 command line (but, curiously, "gcc test.h" uses the joined spelling).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105355
Bug ID: 105355
Summary: -msmall-data-limit= unexpectedly accepts a separate
argument
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99903
--- Comment #3 from Alexey Izbyshev ---
Crashes eventually occurred with both one- and two-processor affinity masks, so
pinning GCC to a single core doesn't help. But I've tracked the reason down.
When `get_time()` from `gcc/timevar.c` gets inli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99903
--- Comment #2 from Alexey Izbyshev ---
> Is there a way to bind GCC to a specific core and test again?
Yes, `repro.py` can be run via `start /affinity MASK`. I've started two
experiments, with one- and two-processor masks. They haven't crashed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99903
Bug ID: 99903
Summary: 32-bit x86 frontends randomly crash while reporting
timing on Windows
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
12 matches
Mail list logo
