https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98418
Bug ID: 98418
Summary: Valid integer constant expressions based on
expressions that trigger -Wshift-overflow are treated
as non-constants
Product: gcc
Version: 6.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98418
--- Comment #2 from pskocik at gmail dot com ---
You're right. The bug was in my code.
struct foo { unsigned bit: (0xll<<40)!=0; };
is indeed UB due to http://port70.net/~nsz/c/c11/n1570.html#6.5.7p4, but
struct foo { unsigned bit: (0xf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98418
pskocik at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85927
Petr Skocik changed:
What|Removed |Added
CC||pskocik at gmail dot com
--- Comment #5 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102096
Bug ID: 102096
Summary: Gcc unnecessarily initializes indeterminate variables
passed across function boundaries
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107831
Bug ID: 107831
Summary: Missed optimization: -fclash-stack-protection causes
unnecessary code generation for dynamic stack
allocations that are clearly less than a page
Pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107831
--- Comment #1 from Petr Skocik ---
Sidenote regarding the stack-allocating code for cases when the size is not
known to be less than pagesize: the code generated for those cases is quite
large. It could be replaced (at least under -Os) with a c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107831
--- Comment #6 from Petr Skocik ---
(In reply to Jakub Jelinek from comment #2)
> (In reply to Petr Skocik from comment #1)
> > Sidenote regarding the stack-allocating code for cases when the size is not
> > known to be less than pagesize: the c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107831
--- Comment #7 from Petr Skocik ---
(In reply to Jakub Jelinek from comment #4)
> Say for
> void bar (char *);
> void
> foo (int x, int y)
> {
> __attribute__((assume (x < 64)));
> for (int i = 0; i < y; ++i)
> bar (__builtin_alloca (x))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107831
--- Comment #9 from Petr Skocik ---
Regarding the size of alloca/VLA-generated code under -fstack-clash-protection.
I've played with this a little bit and while I love the feature, the code size
increases seem quite significant and unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108194
Bug ID: 108194
Summary: GCC won't treat two compatible function types as
compatible if any of them (or both of them) is
declared _Noreturn
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108194
Petr Skocik changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #5 from Petr Skocik --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108194
--- Comment #6 from Petr Skocik ---
(In reply to Petr Skocik from comment #5)
> (In reply to Andrew Pinski from comment #4)
> > Invalid as mentioned in r13-3135-gfa258f6894801a .
>
> I believe it's still a bug for pre-c2x __typeof.
> While it i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106116
Bug ID: 106116
Summary: Missed optimization: in no_reorder-attributed
functions, tail calls to the subsequent function could
just be function-to-function fallthrough
Produc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114011
Bug ID: 114011
Summary: Feature request: __goto__
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114097
Bug ID: 114097
Summary: Missed register optimization in _Noreturn functions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10837
Petr Skocik changed:
What|Removed |Added
CC||pskocik at gmail dot com
--- Comment #19 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114097
--- Comment #4 from Petr Skocik ---
Excellent! Thank you very much. Didn't realize the functionality was already
there, but didn't work without an explicit __attribute((noreturn)). Now I can
get rid of my most complex assembly function which I s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112844
--- Comment #2 from Petr Skocik ---
(In reply to Jakub Jelinek from comment #1)
> With -Os you ask the code to be small. So, while internally the hint is
> still present in edge probabilities, -Os is considered more important and
> certain code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106116
--- Comment #4 from Petr Skocik ---
It would be interesting to do this at the assembler level, effectively
completely turning what's equivalent to `jmp 1f; 1:` to nothing. This would
also be in line with the GNU assembler's apparent philosophy t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108799
Petr Skocik changed:
What|Removed |Added
CC||pskocik at gmail dot com
--- Comment #3 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109567
Bug ID: 109567
Summary: Useless stack adjustment by 16 around calls with odd
stack-argument counts on SysV x86_64
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94379
--- Comment #2 from Petr Skocik ---
Excellent!
For optional super extra coolness, this might work (and clang doesn't do this)
with statement expressions too so that statement expression-based macros could
be
marked warn_unused_result through it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93265
--- Comment #3 from Petr Skocik ---
Here's another example (which may be summarizing it more nicely)
struct a{ char _[4]; };
#include
int cmp(struct a A, struct a B){ return !!memcmp(&A,&B,4); }
Expected x86-64 codegen (✓ for gcc -O2/-O3 and f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109704
Bug ID: 109704
Summary: #pragma {push,pop}_macro broken for identifiers that
contain dollar signs at nonfirst positions
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109766
Bug ID: 109766
Summary: Passing doubles through the stack generates a stack
adjustment pear each such argument at -Os/-Oz.
Product: gcc
Version: unknown
Status: UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90181
Petr Skocik changed:
What|Removed |Added
CC||pskocik at gmail dot com
--- Comment #16 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93487
--- Comment #5 from Petr Skocik ---
Another case of a missed tailcall which might warrant a separate mention:
struct big{ long _[10]; };
void takePtr(void *);
void takeBigAndPassItsAddress(struct big X){ takePtr(&X); }
This should i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112844
Bug ID: 112844
Summary: Branches under -Os (unlike -O{1,2,3}) do not respect
__builtin_expect hints
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #71 from Petr Skocik ---
An Ignore macro that works everywhere where a (void) cast syntactically works
(i.e., even on void types for whatever reason) is easy:
#define IGN$(Val) (__extension__({ \
__auto_type IGN$ = _Generic((typ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60551
Petr Skocik changed:
What|Removed |Added
CC||pskocik at gmail dot com
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112844
--- Comment #3 from Petr Skocik ---
Is there maybe a knob I can turn so I can keep the -Os codegen but have
branches unconditionally laid out in accordance with my __builtin_expect hints?
32 matches
Mail list logo
