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/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59783
--- Comment #3 from Daniel Santos ---
(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!
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.santos at pobox dot com
Target Milestone: ---
Created attachment 36814
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36814&action=edit
simple test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68507
--- Comment #1 from Daniel Santos ---
Correction: xmm6-15, I can't type today. And here is the output on gcc 4.9.3:
$ objdump -dSr test_case.o
test_case.o: file format elf64-x86-64
Disassembly of section .text:
:
0:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68507
--- Comment #3 from Daniel Santos ---
(In reply to Andrew Pinski from comment #2)
> I think there is an ABI difference with respect of xmm6-16 between sysv ABI
> and windows ABIs. Can you provide why you think this is not a bug?
Ehem, uh no. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68507
--- Comment #4 from Daniel Santos ---
According to § 3.2.1 "Registers and the Stack Frame" of the System V
Application Binary Interface for AMD64
Registers %rbp, %rbx and %r12 through %r15 “belong” to the calling function and
the called function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68507
Daniel Santos changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54829
--- Comment #9 from Daniel Santos ---
I appologize for my late response.
(In reply to Richard Earnshaw from comment #8)
> Unfortunately, computers don't to infinite precision arithmetic by default.
> That would perform a different comparison in
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782
--- Comment #2 from Daniel Santos ---
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 of the function under all circumstance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782
--- Comment #6 from Daniel Santos ---
(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 and a failure
> to inline an indirect cal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782
--- Comment #10 from Daniel Santos ---
(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 has the same issues as always
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36631
--- Comment #15 from Daniel Santos ---
ack, undoing, so sorry!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54829
Daniel Santos changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68931
Daniel Santos changed:
What|Removed |Added
CC||daniel.santos at pobox dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68931
--- Comment #5 from Daniel Santos ---
Created attachment 49393
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49393&action=edit
Patch for musl compatibility
The root problem is that musl defines off64_t and loff_t as preprocessor
macros.
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.santos at pobox dot com
Target Milestone: ---
When declaring pointer to a member function pointer using atuo& as the
function's return type, we get a bad parse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98441
--- Comment #1 from Daniel Santos ---
Also, I build gcc with:
-O42 -ffast-math -ffuzzy-dice -felide-function-bodies -pipe-clogged
but that shouldn't make a difference.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98441
--- Comment #4 from Daniel Santos ---
Created attachment 49850
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49850&action=edit
Gentoo gcc 10.2.0-r2 patches
(In reply to Jonathan Wakely from comment #3)
> (In reply to Daniel Santos from co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98441
--- Comment #6 from Daniel Santos ---
(In reply to Jonathan Wakely from comment #5)
> That's why you're asked to provide the output of 'gcc -v' by the
> instructions at https://gcc.gnu.org/bugs/ (because we can't guess that your
> 10.2.0 is diffe
101 - 121 of 121 matches
Mail list logo
