https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119661
Bug ID: 119661
Summary: Possible "accepts invalid": member access into
incomplete type 'struct s'
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119624
--- Comment #5 from Pavel M ---
(In reply to Joseph S. Myers from comment #3)
> because the lvalues are evaluated *relative to that expression*
May be relevant (this is a fragment, see the full answer at
https://stackoverflow.com/a/74876126/177
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119624
Bug ID: 119624
Summary: GCC rejects valid C11 code involving _Generic
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118853
Pavel M changed:
What|Removed |Added
CC||pavel.morozkin at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=01
Bug ID: 01
Summary: -finline-small-functions may invert FP arguments
breaking FP bit accuracy in case of NaNs
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110105
--- Comment #4 from Pavel M ---
To: rsand...@gcc.gnu.org
Thanks! I confused __fp16 with _Float16.
However, if __fp16 is only a “storage type”, then why this code:
__fp16 mul(__fp16 x, __fp16 y)
{
return x * y;
}
compiled with -O3 -mfpu=fp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110105
--- Comment #1 from Pavel M ---
Demo: https://godbolt.org/z/9s7eb9b1K.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110105
Bug ID: 110105
Summary: ARM GCC: underoptimization: expected vfma.f16, actual
vcvtb-vfma.f32-vcvtb
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51437
--- Comment #18 from Pavel M ---
(In reply to Jonathan Wakely from comment #17)
> (In reply to Josh Triplett from comment #5)
> > I'd like to see this as well. While issuing such a warning by default would
> > cause numerous warnings with existi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106797
--- Comment #2 from Pavel M ---
Observation: if "static" is removed, then GCC generates:
: In function 'f2':
:10:18: error: conflicting types for 'x'; have 'int (*)[5]'
10 | extern int (*x)[5];
| ^
:5:18: note: prev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106797
Bug ID: 106797
Summary: Improvement: diagnose undefined behavior: not all
declarations that refer to the same object or function
have compatible type
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51437
Pavel M changed:
What|Removed |Added
CC||pavel.morozkin at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106138
--- Comment #7 from Pavel M ---
May be useful: https://devblogs.microsoft.com/cppblog/new-code-optimizer.
Search for "Bit Estimator" section containing "Folding comparisons and
branches".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106138
Bug ID: 106138
Summary: Inefficient code generation for cases when results can
be deduced at compile time
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3885
Pavel M changed:
What|Removed |Added
CC||pavel.morozkin at gmail dot com
--- Comment #15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105488
--- Comment #3 from Pavel M ---
To: Andrew Pinski
Indeed, per C11:
> It is unspecified whether a call to the function uses the inline definition
> or the external definition.
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105488
Bug ID: 105488
Summary: Function definition is not generated OR function is
not inlined
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105362
--- Comment #2 from Pavel M ---
I do believe that evaluation of constant expressions in conditional inclusion
is done according to the rules of constant expressions ("except that ...", see
C11, 6.10.1/1). Hence, I expect the same diagnostics in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105362
Bug ID: 105362
Summary: Improvement: diagnose undefined behavior in
preprocessing directives
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105207
--- Comment #4 from Pavel M ---
To: Andrew Pinski
At the 1st glance I expected to see that -E produces the output after splicing
is done (i.e. xxx #error). However, the "preprocessing only" is out of scope of
the C11. As stackoverflow.com user
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105207
Pavel M changed:
What|Removed |Added
Summary|C preprocessor: splicing|Translation phase 2:
|physi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105207
--- Comment #1 from Pavel M ---
The same behavior with:
xxx \
error
Expected:
xxx error
Actual:
xxx
error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105207
Bug ID: 105207
Summary: C preprocessor: splicing physical source lines to form
logical source lines may not work
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104147
Bug ID: 104147
Summary: C preprocessor may remove the standard required
whitespace between the preprocessing tokens
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104095
Bug ID: 104095
Summary: g++ diagnosis may use non-standard terminology:
"constant" instead of "literal", "integer" instead of
"integral"
Product: gcc
Version: 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584
Pavel M changed:
What|Removed |Added
CC||pavel.morozkin at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103491
--- Comment #4 from Pavel M ---
To: jos...@codesourcery.com
Re: This testcase is incorrect.
Indeed. The F.10.8.3 was misunderstood.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103491
Bug ID: 103491
Summary: nextafter does not raise "overflow" and "inexact"
floating-point exceptions
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20785
--- Comment #16 from Pavel M ---
Note: The #pragma STDC FENV_ACCESS is unknown and ignored (leading to FP
issues), however, the __STDC_IEC_559__ is defined to 1. Confused.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103193
Bug ID: 103193
Summary: gcc for x86_64: wrong code generation: ucomiss instead
of comiss
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20785
--- Comment #14 from Pavel M ---
To: Vincent Lefèvre
Re: the warnings are useless.
The "warning: ignoring '#pragma STDC FENV_ACCESS' [-Wunknown-pragmas]" probably
needs to be generated by default (i.e. not with -Wall) because now gcc silently
mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20785
Pavel M changed:
What|Removed |Added
CC||pavel.morozkin at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102821
--- Comment #2 from Pavel M ---
Addition to "Notes" above.
3. C11, 5.1.1.3 Diagnostics, 1:
> A conforming implementation shall produce at least one diagnostic message
> (identified in an implementation-defined manner) if a preprocessing
> tra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102821
Bug ID: 102821
Summary: Tentative definition of variable with internal linkage
has incomplete non-array type: missing diagnostics
Product: gcc
Version: 11.2.0
Status: UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101063
Bug ID: 101063
Summary: #pragma STDC FENV_ACCESS ON: wrong code generation:
instructions leading to side effects may not be
generated
Product: gcc
Version: 11.1.
35 matches
Mail list logo