[Bug c/61939] New: warn when __attribute__((aligned(x))) is ignored

2014-07-28 Thread daniel.santos at pobox dot com
: c Assignee: unassigned at gcc dot gnu.org Reporter: daniel.santos at pobox dot com Sadly, I had been using the following code, presuming that I was telling gcc that some data was aligned: void copy_something(void *p, const void *s) { struct some_struct __aligned__((aligned

[Bug c++/36631] [4.3 Regression] attribute always_inline - sorry, unimplemented: recursive inlining

2014-07-28 Thread daniel.santos at pobox dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36631 --- Comment #15 from Daniel Santos daniel.santos at pobox dot com --- ack, undoing, so sorry!

[Bug web/61782] always_inline incorrectly documented

2014-07-16 Thread daniel.santos at pobox dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782 --- Comment #10 from Daniel Santos daniel.santos at pobox dot com --- (In reply to rguent...@suse.de from comment #7) Heh - I've been there as well and guess what - I invented __attribute__((flatten)) because of this... Note that flatten

[Bug web/61782] always_inline incorrectly documented

2014-07-15 Thread daniel.santos at pobox dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782 --- Comment #6 from Daniel Santos daniel.santos at pobox dot com --- (In reply to Richard Biener from comment #3) Note that if such function is called indirectly the compiler may or may not inline it dependent on optimization level

[Bug web/61782] always_inline incorrectly documented

2014-07-14 Thread daniel.santos at pobox dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782 --- Comment #2 from Daniel Santos daniel.santos at pobox dot com --- Hmm, I suppose I wasn't considering that interpretation of the language. Your clarification helps though, and actually sounds pretty good: always_inline forces inlining

[Bug web/61782] New: always_inline incorrectly documented

2014-07-11 Thread daniel.santos at pobox dot com
Assignee: unassigned at gcc dot gnu.org Reporter: daniel.santos at pobox dot com The current behavior of __attribute__((always_inline)) is to not only inline in -O0, but also to force inlining even when -finline-limit is exceeded. However, the documentation states that it will only

[Bug other/59783] inline expansion stack when attribute error/warning triggered is displayed incorrectly

2014-01-13 Thread daniel.santos at pobox dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59783 --- Comment #3 from Daniel Santos daniel.santos at pobox dot com --- (In reply to Jakub Jelinek from comment #2) If you want precise call trace in the diagnostics, you need to use -g. holy backtrace batman!

[Bug other/59783] New: inline expansion stack when attribute error/warning triggered is displayed incorrectly

2014-01-12 Thread daniel.santos at pobox dot com
Severity: minor Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: daniel.santos at pobox dot com In C C11, __attribute__((error())) is a wonderful replacement for _Static_assert() (e.g., http://git.kernel.org/cgit/linux/kernel/git

[Bug tree-optimization/58005] missed optimization printf constant string

2013-09-23 Thread daniel.santos at pobox dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58005 Daniel Santos daniel.santos at pobox dot com changed: What|Removed |Added CC

[Bug driver/58512] New: [Feature request] -Wformat extensions to accomodate custom rules

2013-09-23 Thread daniel.santos at pobox dot com
Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: daniel.santos at pobox dot com I am working on a Linux kernel patch set to add a feature comprable to glibc's %m format specifier. However, glibc's extensions uses errno which

[Bug driver/58512] [Feature request] -Wformat extensions to accomodate custom rules

2013-09-23 Thread daniel.santos at pobox dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58512 --- Comment #2 from Daniel Santos daniel.santos at pobox dot com --- Ahh, thanks so much! Sorry I failed to find the related bugs. :(

[Bug c++/57977] zero-length const array in union prohibits default copy xtor

2013-07-25 Thread daniel.santos at pobox dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57977 --- Comment #2 from Daniel Santos daniel.santos at pobox dot com --- Don't you mean the part which prohibits its creation?

[Bug c++/57977] zero-length const array in union prohibits default copy xtor

2013-07-25 Thread daniel.santos at pobox dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57977 --- Comment #3 from Daniel Santos daniel.santos at pobox dot com --- Hmm, I guess it's actually the copy assignment operator. Either way, it makes sense if the const union member was real, in this case, the copy assignment for this member would

[Bug c++/57977] New: zero-length const array in union prohibits default copy xtor

2013-07-24 Thread daniel.santos at pobox dot com
Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: daniel.santos at pobox dot com #include iostream union a { struct { const char string[0]; } b; }; int main(int argc, char *argv[]) { std::cout size = sizeof(union

[Bug c/55678] New: _Static_assert escapes tick marks just to make me mad

2012-12-13 Thread daniel.santos at pobox dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55678 Bug #: 55678 Summary: _Static_assert escapes tick marks just to make me mad Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal

[Bug c/55678] _Static_assert escapes tick marks just to make me mad

2012-12-13 Thread daniel.santos at pobox dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55678 --- Comment #1 from Daniel Santos daniel.santos at pobox dot com 2012-12-13 21:12:24 UTC --- This appears to happen in the function c_parser_static_assert_declaration_no_semi (gcc/c/c-parser.c) when it calls c_parser_peek_token (parser

[Bug target/54829] bad optimization: sub followed by cmp w/ zero (x86 ARM)

2012-11-15 Thread daniel.santos at pobox dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54829 --- Comment #7 from Daniel Santos daniel.santos at pobox dot com 2012-11-15 21:56:02 UTC --- First off, I apologize for my late response here. (In reply to comment #5) I'm going to respond a little backwards.. In fact, on ARM

[Bug target/54829] bad optimization: sub followed by cmp w/ zero (x86 ARM)

2012-10-06 Thread daniel.santos at pobox dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54829 Daniel Santos daniel.santos at pobox dot com changed: What|Removed |Added Summary|bad optimization: sub |bad

[Bug target/54829] bad optimization: sub followed by cmp w/ zero (x86 ARM)

2012-10-06 Thread daniel.santos at pobox dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54829 --- Comment #4 from Daniel Santos daniel.santos at pobox dot com 2012-10-06 15:57:15 UTC --- Please help me out here if I am missing something.

[Bug target/54829] New: bad optimization: sub followed by cmp w/ zero (x86 ARM)

2012-10-05 Thread daniel.santos at pobox dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54829 Bug #: 54829 Summary: bad optimization: sub followed by cmp w/ zero (x86 ARM) Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED

[Bug rtl-optimization/3507] appalling optimisation with sub/cmp on multiple targets

2012-07-10 Thread daniel.santos at pobox dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3507 Daniel Santos daniel.santos at pobox dot com changed: What|Removed |Added CC

<    1   2