Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: izbyshev at ispras dot ru
CC: amonakov at gcc dot gnu.org
Target Milestone: ---
$ cat test.c
void foo(int x, int
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: izbyshev at ispras dot ru
Target Milestone: ---
Host: i686-w64-mingw32
Target: i686-w64-mingw32
Build: i686-w64-mingw32
Created attachment
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
--- 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=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]
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: izbyshev at ispras dot ru
Target Milestone: ---
Target: riscv64-linux-gnu
"msmall-data-limit=" is marked as both Joined and Separate at
https://gcc.gnu.org/git?p
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).
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: izbyshev at ispras dot ru
CC: amonakov at gcc dot gnu.org
Target Milestone: ---
GCC preprocessor appears to behave as if each _Pragma(pop_macro("m"))
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
--- 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 #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
erity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: izbyshev at ispras dot ru
Target Milestone: ---
auto f(int n) {
int (*a)[n] = 0;
return a;
}
int g() {
return sizeof *f(1);
}
Output of GCC 12.2:
during RTL
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,
13 matches
Mail list logo
