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(); }
This should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90181
Petr Skocik changed:
What|Removed |Added
CC||pskocik at gmail dot com
--- Comment #16
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10837
Petr Skocik changed:
What|Removed |Added
CC||pskocik at gmail dot com
--- Comment #19
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
Consider a never-returning functions such as this:
#include
#include
//_Noreturn
void noret(unsigned A, unsigned B, unsigned C, unsigned D, unsigned E, jmp_buf
Jb
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
Gcc has __volatile__.
I can only assume the rationale for it is so that inline asm macros can
do __asm __volatile__ and not have to worry about user-redefines of the
volatile keyword (which while
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
A simple example that demonstrates this is:
int test(void);
void yes(void);
void expect_yes(void){ if (__builtin_expect(test
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
: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
/*
Passing doubles through the stack generates a stack adjustment pear each such
argument
: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
This following dollarsign-less example compiles fine as expected:
#define MACRO 1
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(,,4); }
Expected x86-64 codegen (✓ for gcc -O2/-O3 and for
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
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
For function calls with odd stack argument counts, gcc generates a useless `sub
$16, %rsp` at the beginning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108799
Petr Skocik changed:
What|Removed |Added
CC||pskocik at gmail dot com
--- Comment #3
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108194
Petr Skocik changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #5 from Petr Skocik
: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
(same with __attribute((noreturn))) Example (https://godbolt.org/z
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
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
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
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
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
I'm talking allocations such as
char
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
Example:
__attribute((noinline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85927
Petr Skocik changed:
What|Removed |Added
CC||pskocik at gmail dot com
--- Comment #5
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
Compared to clang where:
long ret_unspec(void){ auto long rv; return rv; }
void take6(long,long,long,long,long
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=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 { unsign
: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
This causes things like:
struct foo { unsigned bit: (0xll<
bit-offset
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
Gcc doesn't silence -Wsign-conversion warnings in the expansion of
system-header macros (e.g., in the expansion of Musl's/Cygwin's FD_SET
rmal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
Created attachment 48777
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48777=edit
preprocessed reproducer that cras
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
Example:
For:
struct small{ short a,b; signed char c; };
void call_func(void)
{
extern int func(struct small X);
static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94703
--- Comment #11 from pskocik at gmail dot com ---
Thanks for the shot at a fix, Richard Biener.
Since I have reported this, I think I should mentioned a related suboptimality
that should probably be getting fixed alongside with this (if this one
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
The problem, demonstrated in code examples below, can be suppressed by
memcpying into a union (possibly just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93487
--- Comment #3 from pskocik at gmail dot com ---
The gist of this along with https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93540
is "please make trivial aggregates (i.e., aggregates, which are ultimately a
native type) a true zero-cost abstra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
pskocik at gmail dot com changed:
What|Removed |Added
CC||pskocik at gmail dot com
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
Clang supports applying the warn_unused_result attribute to enums, structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87313
pskocik at gmail dot com changed:
What|Removed |Added
CC||pskocik at gmail dot com
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
Example:
#define SIMPLE 0
#include
#if SIMPLE
typedef int TYPE;
#else
typedef struct TYPE { int a; } TYPE
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
Given, for example:
#include
typedef union lp_tp {
long l;
void *p;
} lp_tp ;
typedef union ilp_tp{
int i
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
I have a lot of cases where I'd like to translate boolean conditions to negated
errno codes (possibly wrapped in an struct or a trivial union).
If this translation
: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
int x [ _Generic(0,int: !0) < 10 ]; //falsely triggers
-Wlogi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26724
pskocik at gmail dot com changed:
What|Removed |Added
CC||pskocik at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91298
--- Comment #7 from pskocik at gmail dot com ---
(In reply to CVS Commits from comment #6)
> The master branch has been updated by Jakub Jelinek :
Thank you for the fix!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91298
pskocik at gmail dot com changed:
What|Removed |Added
CC||pskocik at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93239
--- Comment #1 from pskocik at gmail dot com ---
Fixing this seems as simple as removing/commenting-out:
gcc/c/c-parser.c:8195 /* If we've not yet started the current function's
statement list,
gcc/c/c-parser.c:8196or we're
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92935
--- Comment #3 from pskocik at gmail dot com ---
jos...@codesourcery.com, that's interesting, but it seems like an unnecessary,
weird special case, considering that gcc already has a qualifier-dropping
mechanism that doesn't necessitate special
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92935
pskocik at gmail dot com changed:
What|Removed |Added
CC||pskocik at gmail dot com
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone
: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
About the simplest example of this I could
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
I've noticed gcc seems to syntactically disallow statement expressions at
filescope even in contexts where they wouldn't be evaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93180
--- Comment #5 from pskocik at gmail dot com ---
Jakub Jelinek, I later asked how this worked on Stack Overflow
(https://stackoverflow.com/questions/59629946/why-do-gcc-and-clang-place-custom-sectioned-const-funcptr-symbols-into-writable).
Got
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93180
--- Comment #3 from pskocik at gmail dot com ---
Thanks for explaining. Yes, -fPIC does cause the section to become writable on
clang.
I'm currently toying with using a custom section to gather const
function-pointers, but this -fPIC stuff
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
__attribute((__section__("mysection"))) int const cx = -42;
(or with multiple const data
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
The problem appears to exist on all gcc versions.
Example Code:
#define BX_gcc_push(Category,...) BX_pragma(GCC Category push
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
I test-compiled ( https://gcc.godbolt.org/z/8bhbNa ):
__attribute((optimize(3))) int div(int X) { return X/3; }
with -O{0,1,2,3,s}, expecting to get the same assembly in all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39985
pskocik at gmail dot com changed:
What|Removed |Added
CC||pskocik at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
pskocik at gmail dot com changed:
What|Removed |Added
CC||pskocik at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66918
--- Comment #8 from pskocik at gmail dot com ---
I'd also very much welcome a way to silence this (like with
-Wno-undefined-inline on clang).
My reason for wanting it is I'd like to prototype a non-static inline function
in one header (a fast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66918
pskocik at gmail dot com changed:
What|Removed |Added
CC||pskocik at gmail dot com
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
void f() { struct{ unsigned x:1; }x = { (unsigned){0} }; }
warns about a conversion to `unsigned char:1`. It should say `unsigned int:1`.
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
void f() { struct{ unsigned x:1; }x = { (unsigned){0} }; }
warns about a conversion to `unsigned char:1`. It should say `unsigned int:1`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45591
pskocik at gmail dot com changed:
What|Removed |Added
CC||pskocik at gmail dot com
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
I noticed gcc 7.* did a really nice optimization that allowed me to communicate
I want even some unsigned overflows to be
undefined:
#define
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
`gcc -S pp_assembly.S -o OutFile.s` or
`gcc -S pp_assembly.sx -o OutFile.s` or should behave the same as
`gcc -E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82335
--- Comment #1 from pskocik at gmail dot com ---
This problem still persists in gcc 7.3.0. It appears pasting a macro containing
`_Pragma`s into
another macro is what's causing the displacement of the generated `#pragma`s.
I've cleaned up
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
Created attachment 42239
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42239=edit
reproducer for "Incorrect _Pragma e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15351
pskocik at gmail dot com changed:
What|Removed |Added
CC||pskocik at gmail dot com
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
Example:
touch in.h
gcc -x c -include in.h - -MD -MF /dev/stdout <<<'int main(){x; return 42;}
fails as it should.
Changing -MD to -MM causes the failure to go undetected (no stde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77487
pskocik at gmail dot com changed:
What|Removed |Added
CC||pskocik at gmail dot com
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
My program calls `gcc -x c - ` with the offset of filedescriptor 0 being larger
than 0.
Cons
72 matches
Mail list logo
