[Bug c/38295] New: Support pointer difference as constant in static initializer

on: 4.3.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gnu at behdad dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38295

[Bug c/38295] Support pointer difference as constant in static initializer

--- Comment #2 from gnu at behdad dot org 2008-11-27 18:31 --- I'm not following. Why arrays? Those are pointers, and their difference is known at compile time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38295

[Bug c/38295] Support pointer difference as constant in static initializer

--- Comment #3 from gnu at behdad dot org 2008-11-27 18:32 --- Oh, I see what you mean. Yes, I said in my report that this is undefined/unsupported/... according to the C standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38295

[Bug c/38295] Support pointer difference as constant in static initializer

--- Comment #5 from gnu at behdad dot org 2008-11-27 18:35 --- If the two functions are in the same compilation unit (and static), it's known at compile time, isn't it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38295

[Bug c/38295] Support pointer difference as constant in static initializer

--- Comment #8 from gnu at behdad dot org 2008-11-27 18:55 --- If they are asked to be put in different sections, sure, it will err. But doesn't gcc already use relative calls for many static functions in the same unit? Let me back out: my request is: add gcc extension to su

[Bug c/38354] New: Spurious error: initializer element is not computable at load time

error: initializer element is not computable at load time Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gnu at behdad dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38354

[Bug c/38354] Spurious error: initializer element is not computable at load time

--- Comment #2 from gnu at behdad dot org 2008-12-01 23:38 --- It's not a useful use case, agreed, but I don't see how that affects the computability of a value at "load time", whatever that means. It did trick me: I was converting a vtable to use label values, a

[Bug c/38481] New: Add attribute for custom sentinels

: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gnu at behdad dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38481

[Bug c/28875] New: "-Wextra -Wno-unused-parameter -Wall" doesn't work as expected

gned at gcc dot gnu dot org ReportedBy: gnu at behdad dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28875

[Bug c/28876] New: Provide -W options for all warnings enabled by -Wextra

Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gnu at behdad dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28876

[Bug c/29445] New: Add attribute for 'experimental'

cc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gnu at behdad dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29445

[Bug c/32911] New: Function __attribute__ ((idempotent))

all... Thanks, -- Summary: Function __attribute__ ((idempotent)) Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

--- Comment #5 from gnu at behdad dot org 2007-08-13 05:40 --- (In reply to comment #2) > If the compiler could tell whether you were right or not in all cases, you > wouldn't need the attributes in the first place. This is not completely true though: the compiler cannot t